Hi I am looking to get a simple consensus on what everyone uses Qtree's for?
Today we use them for Share access and we also add one every time we add a LUN. Meaning we will created a volume then qtree and then a LUN. I am not sure we need to follow the process or what we gain from doing this?
We use Unix and NTFS based on the share setup so I am not concerned and see value at the share level. I am just looking to see if there is value when created LUN's off of a Qtree level.
Also other uses that users are following would be good to know. I believe for some SnapMirror replications you have to use Qtree's or want to use them based on what you are doing.
we use qtrees for 2 things
1) quotation 😉
2) Qtree SnapMirror and SnapVault asynchronous replication. when using oncommand you must have qtrees
A lun can be moved into a qtree online anytime btw with the lun move command.
Thanks for the reply.
Can anyone else give feedback on what you use Qtree's for in your environment?
We use qtree's for :
- Qtree snapvault and snapmirror.
- I used LUN under qtree, when in the same volume ( in the vfiler0) I had to create two LUN attached to 2 differents Vfilers.
- separate different envirnement in the same volume ( It might hell when you have to restore).
With the risk of getting my butt kicked, I would say that qtrees are dinosaurs that have survived from the days of the Traditional Volumes. In those days, qtrees provided an additional abstraction layer that enabled customers to slice up the volumes into smaller containers with its own size limit. But with the arrival of ONTAP 7.0 the aggregates took the place of the TradVols and the Flexible Volumes was introduced as yet another abstraction layer.
Of course, there are other uses of qtrees:
- QSM/SnapVault => you can use /vol/volname/- as source path to grab data outside qtrees
- User quotas => can be applied on volumes as well
- Security Style => also on volume level
- Enable/disable oplocks => guess what: can be set on volume level
After reading this, you might think that I am an notorious qtree hater but that is not the case. I have happily been using qtrees for 10+ years but I am loosing faith. It's getting harder and harder to convince myself/colleagues/customers to use qtrees for each year that passes. There are more and more features that get more complicated when you try to squeeze in the qtree step. For example when you right click an ESX cluster and create a new datastore from the VSC. It is automatically mounted on all hosts and the only way to get a qtree in to the picture is to unmount it from all hosts, create the qtree, update the NFS export and re-mount it on all hosts. I could always file an RFE and ask NetApp to add qtree support in VSC - but for what reason? Feels like asking Walmart to set up a dinosaur parking outside all of their stores. Why don't we kill that dino instead?
Ok, I can see a couple of obvious use case: if I have >500 file areas that I need to set an individual size limit on, then we run out of FlexVols. Also, if I have a large number of data buckets that I want to move around between different flexvols - QSM is an excellent tool for that! But with clustered ontap, migrations can be done with zero downtime by just migrating the volumes to different nodes and aggregates.
So honestly, why should I continue using qtrees?
We only use them for our luns in readiness for SV
There are limitations for the number of volumes that you can create on a given controller based on the current version of ONTAP as well as the controller model. In large environments that support home drives or many other small shares/exports, it makes sense to create qtrees beneath a volume.
I hope that makes sense!
Edit: YBENDOVER pretty much nailed it
Another useful feature concerning qtrees:
You've got different departments with similar data.
Neither department shall see the data of the others.
With qtrees, you can use storage efficiency .
Place them ALL in one volume with different qtrees,
qtree quotas and exports.
Now use deduplication ...
As deduplication is only possible in a volume,
your benefit will be much better
than with different volumes for each of the departments.
just my 2 cents ...
I agree with the general thoughts expressed - Qtrees are nice when you need that added level of tracking (quota) within a volume, but beyond that they are more hassle then they are worth. They were ceertainly more useful in 7-mode with QSM as compared to Clustered Ontap where only VSM is possible. But similar to a previous reply we have projects that have a common structure - one volume per project, 6 standard qtrees per volume, 1200 active volumes. Qtree's and tracking quotas are the most convenient way report on aggregate cross project type of data volume within a structure element.
I still by habit create a qtree for each user visible share and set a tracking quota on that as well (the administrative version of the share being the volume root). There were certain metrics for which it was just more convenient to have available through tracking quotas in 7-mode/DFM, and some that could only be built into custom reports through the quota data. With Clustered Ontap and the new OCUM/OPM tools I'm still building out my typical dashboard reports as new capabilities are delivered. I suspect that I will curtail using qtrees completely without a specific quota tracking need.
Completely agree with the statement of Bob. Cluster Mode Data ONTAP can only have VSM for protection and if you don't need Quota settings for volumes, there is no use of qtrees.
We needed to SnapMirror data between source and destination controllers which were running slightly different OnTap versions. Apparently, it turns out that volume-level SnapMirror relationships are not supported between inconsistent versions. (It throws a version mismatch error if you try.) We wanted to try to avoid downgrading or upgrading anything (a semi-drastic action) just to support this one relationship.
So, one of our clever admins discovered another "use of QTrees":
It just so happens that even though our OnTap versions were inconsistent (between intended source/destination for Snap relationship), we could get around the problem by SnapMirror'ing at the QTree layer, instead of at the volume layer.