Last time I began talking a little about qtrees. I described qtrees as a kind of mini volume or sub volume, because the have many of the qualities of a volume. Qtrees often seem to be a little controversial in class.
Many people decide not to use them, not seeing any particular advantage, or deciding they are not worth the extra trouble. In some cases, such as a customer who is using the SnapVault product, using qtrees is generally advised and will make the product more useable.
There is another aspect of qtrees that I recently became aware of: the qtree stats command.
Suppose you have a set of volumes and qtrees that all share a single aggregate. Suppose also that these volumes and qtrees are used to support CIFS shares or NFS exports. Performance has degraded over time and you have identified a problem. You have used the statit command and found that disk utilization on this aggregate is too high. The next problem is to identify the exports and shares that are generating most of the load. One possible way of doing this is the qtree stats command.
Here is an example of qtree stats on my simulator:
Obviously, not much is going on with my sim. However, if there were activity, we would be able to identify the number of NFS and CIFS operations by volume and qtree. This is potentially very useful information. Notice, by comparing the output with qtree status, that in this case, the qtree stats command does not track operations by volume:
Exports and shares at the volume level and at the directory level cannot be tracked with qtree stats. But if we had exported and shared at the qtree level we would have an easy way to track utilization of those resources. This makes it relatively easy to see how busy these qtrees are both on an absolute basis as well as relative to one another.