Qtrees and DATA ON TAP

I notice the subject of qtrees is often a source of confusion among students in my Data ONTAP Fundamentals classes. Part of this arises from the fact that, to the best of my knowledge, qtrees are unique to Data ONTAP and part of it come from the way they are often treated on Netapp’s own materials.

Qtrees are often described at “sub volumes”. This is a pretty good starting point. Qtree have many of the qualities of volumes in Data ONTAP. I have also heard people refer to them as super directories. Again, this is not a bad way of looking at qtrees either. To hosts access a volume with qtrees, they look like directories, yet they have many of the qualities of a volume.

Volumes all exist immediately below the root volume in the Data ONTAP file structure. The full path name for every volume starts with “/vol” and then the volume name. It is not possible to have a volume within a volume, so all volumes “plug in” at the same place, to /vol.

Qtree are similar. They exist inside volumes and they “plug in” to the volume at the root of that volume. The basic directory structure within Data ONTAP is “/vol/<vol_name>/<qtree_name>. Every volume plugs into the root “/vol” and every qtree plugs into the root of the volume. Nesting a qtree inside a qtree or under a directory is not supported.

Like volumes, qtrees have associated security styles. For volumes, the default security style is UNIX. (This can be modified though the options default.wafl_security_style setting, or by running CIFS setup and selecting NTFS only). For qtrees, the default security style is matched to the volume which contains the qtree. If we create a qtree in volume with the NTFS security style, that volume will also have a security style setting of NTFS. Of course, we can change it after creation with the “qtree security” command.

However, if we delve a little deeper, we will notice some inconsistencies. Look at this output from the qtree status command:

The qtree status command lists the qtrees on this system. It also lists the volumes. Also notice that if I want to change the security style of a qtree I use the “qtree security <path>” command. This is what I would expect. However, to change the security style on a volume, I also use the qtree security command:

This seems odd. From this it seems fair to deduce that every volume has an implicit qtree that goes by the same name as the volume.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

2 Responses to “Qtrees and DATA ON TAP”

  1. Bobby on 13 Jun 2010 at 2:55 pm #

    Thank you this was very helpful.

  2. L Steinke on 11 Mar 2011 at 2:21 pm #

    Thank you for the article. It did a good job of describing how qtree works in a practical sense along with some of the unexpected oddities I might encounter when looking up commands. For example, suppose I wanted to disable oplocks on a VOLUME /vol/vol1 would I run “qtree oplocks /vol/vol1 disable” even though I do not have any qtrees installed on the volume /vol/vol1 ? From a casual read of your article I would expect the anser to be “yes, run ‘qtree oplocks /vol/vol1 disable’ to disable oplocks on the VOLUME /vol/vol1 that contains no user-created qtrees.

    Am I correct?

Trackback URI |

Live Chat