qtree
NAME
qtree – create and manage qtrees
SYNOPSIS
qtree create name [ -m mode ]qtree oplocks name [ enable | disable ]
qtree security name [ unix | ntfs | mixed ]
qtree status [ -i ] [ -v ] [ name ]
qtree stats [ -z ] [ name ]
DESCRIPTION
The qtree command creates qtrees and specifies attributes for qtrees.A qtree is similar in concept to a partition. It creates a subset of a volume to which a quota can be applied to limit its size. As a special case, a qtree can be the entire volume. A qtree is more flexible than a partition because you can change the size of a qtree at any time.
In addition to a quota, a qtree possesses a few other properties.
A qtree enables you to apply attributes such as oplocks and security style to a subset of files and directories rather than to an entire volume.
Single files can be moved across a qtree without moving the data blocks. Directories cannot be moved across a qtree. However, since most clients use recursion to move the children of directories, the actual observed behavior is that directories are copied and files are then moved.
Qtrees represent the third level at which filer storage can be partitioned. Disks are organized into aggregates which provides pools of storage. In each aggregate, one or more flexible volumes can be created. Traditional volumes may also be created directly without the previous creation of an aggregate. Each volume contains a file system. Finally, the volume can be divided into qtrees.
If there are files and directories in a volume that do not belong to any qtrees you create, the filer considers them to be in qtree 0. Qtree 0 can take on the same types of attributes as any other qtrees.
You can use any qtree command whether or not quotas are enabled on your filer.
USAGE
The qtree create command creates a qtree. If name does not begin with a slash (/), the qtree is created in the root volume. To create a qtree in a particular volume, specify name in this format: /vol/vol_name/qtree_name.A qtree can be created only in the root directory of a volume. By default, a qtree has the same security style as the root directory of the volume and oplocks are enabled. The root directory of a volume, by default, uses the unix security style.
When you create a qtree, you can optionally specify the file permission bits of the qtree using the mode option. The format of the mode option is similar to UNIX permission bits: 0755 gives read/write/execute permissions to owner and read/execute to group and other users. It consists of 4 octal digits derived by adding up bits 4, 2, and 1. Omitted digits are assumed to be zeros. The first digit selects the set user ID (4), set group ID
- (2),
- and sticky attributes. The second digit selects permissions for the owner of the file: read (4), write (2), and execute ; the third selects permissions for other users in the same group; the fourth for other users not in the group. If this argument is missing, the permission bits are set using the value of the option "wafl.default_qtree_mode”.
To delete a qtree, remove it from a client as you would any directory. There is a limit of 4994 qtrees per volume.
If you do not specify the name in the "qtree" command, the attributes for all quota trees on the filer are displayed.
The qtree oplocks command enables or disables oplocks for files and directories in a qtree or in a volume. If name is the path name to a qtree, the attribute applies to files and directories in the specified qtree. The path name to a quota tree does not need to end with a slash. If name is the path name to a volume, the attribute applies to those files and directories in qtree 0. The path name to a volume must end with a slash.
If the cifs.oplocks.enable option is off, oplocks are not sent even if you enable the oplocks on a per-quota-tree basis with the qtree oplocks command. The cifs.oplocks.enable option is enabled by default.
If you do not specify enable or disable in the qtree oplocks command, the oplock attribute for name is displayed.
The qtree security command changes the security style for files and directories. Security style means the method the filer uses to determine whether a user has access to a file. If name is the path name to a qtree, the security style applies to the files and directories in the specified qtree. The path name to a qtree does not need to end with a slash. If name is a path name to a volume, the security style applies to those directories and files in qtree 0. Any new qtree you create inherits the security style from qtree 0 by default. The path name to a volume must end with a slash.
The security style can be one of the following values:
- unix
- The user’s UID and GID, and the UNIX-style permission bits of the file or directory determine user access. The filer uses the same method for determining access for both NFS and CIFS requests. If you change the security style of a qtree or a volume from ntfs to unix, the filer disregards the Windows NT permissions that were established when the qtree or volume used the ntfs security style.
- ntfs
- For CIFS requests, Windows NT permissions determine user access. For NFS requests, the filer generates and stores a set of UNIX-style permission bits that are at least as restrictive as the Windows NT permissions. The filer grants NFS access only if the UNIX-style permission bits allow the user access. If you change the security style of a qtree or a volume from unix to ntfs, files created before the change do not have Windows NT permissions. For these files, the filer uses only the UNIX-style permission bits to determine access.
- mixed
- Some files in the qtree or volume have the unix security style, and some have the ntfs security style. A file’s security style depends on whether the permission was last set from CIFS or NFS. For example, if a file currently uses the unix security style and a CIFS user sends a setACL request to the file, the file’s security style is changed to ntfs. If a file currently uses the ntfs style and an NFS user sends a setpermission request to the file, the file’s security style is changed to unix.
The qtree status command displays the attributes of all quota trees for volume name on the filer. It displays the containing volume, the tree name, the security style, oplock status, and whether the qtree is snapmirrored or not. The "-i" flag will add an "ID" column which displays the "tree id" – an integer used to identify the qtree in various syslog messages. If vfilers are licensed, the "-v" flag can be used to display the owning vfiler for each qtree.
If you do not specify the name in the "qtree status" command, the attributes for all quota trees on the filer are displayed.
The qtree stats command displays a count of the number NFS/CIFS operations caused by user accesses to files in quota trees. The filer maintains counters for each quota tree in each of the filer’s volumes. The counters are non-persistent.
The "-z" flag can be used to reset the counters.
The values displayed correspond to the operations on qtrees since the volume (in which the qtrees exist) was created or since it was made online on the filer via either a "vol online" command or a filer reboot, or since the counters were last reset, whichever occured most recently.
If you do not specify the name in the "qtree stats" command, the statistics for all quota trees on the filer are displayed. Otherwise, statistics for quota trees in volume name are displayed.
Similarly, if you do not specify the name with the "-z” flag, the counters for all quota trees on all volumes is reset.
EXAMPLES
The following example sets the security style of a qtree named marketing in the root volume to ntfs:toaster> qtree security marketing ntfs
The following example sets the security style of a qtree named engineering in the vol1 volume to ntfs:
toaster> qtree security /vol/vol1/engr ntfs
The following example sets the security style of the root volume to unix:
toaster> qtree security / unix
The following example sets the security style of the vol1 volume to unix:
toaster> qtree security /vol/vol1/ unix
The following example disables oplocks for the engr qtree:
toaster> qtree oplocks /vol/vol1/engr disable
The following example enables oplocks for the vol1 volume:
toaster> qtree oplocks /vol/vol1/ enable
The following example displays the security style, oplocks attribute, and snapmirrored status for all volumes and qtrees on the filer:
toaster> qtree status
Volume Tree Style Oplocks Status ——– ——– —– ——– ——— vol0 unix enabled normal vol0 marketing ntfs enabled normal vol1 unix enabled normal vol1 engr ntfs disabled normal vol1 backup unix enabled snapmirrored
The following example displays the security style, oplocks attribute, and snapmirrored status for the qtrees on vol1 of the filer:
toaster> qtree status vol1
Volume Tree Style Oplocks Status ——– ——– —– ——– ——— vol1 unix enabled normal vol1 engr ntfs disabled normal vol1 backup unix enabled snapmirrored
The following example displays the statistics for all volumes and qtrees on the filer:
toaster> qtree stats
Volume Tree NFS ops CIFS ops ——– ——– ——- ——– vol0 backup 18636 2340 vol1 engr 8636 30 vol1 marketing 36 2000
The following example displays the statistics for the qtrees in vol1 of the filer:
toaster> qtree stats vol1
Volume Tree NFS ops CIFS ops ——– ——– ——- ——– vol1 engr 8636 30 vol1 marketing 36 2000
The following example displays how to clear the counters reported in qtree statistics for the qtrees in vol1 of the filer:
toaster> qtree stats -z vol1
toaster> qtree stats vol1
Volume Tree NFS ops CIFS ops ——– ——– ——- ——– vol1 engr 0 0 vol1 marketing 0 0
SINGLE-FILE MV CONSIDERATIONS
The FSF’s implementation of mv does not use recursion to move the contents of a directory. Their assumption is that if the rename of the directory failed, then the rename of its files will also fail. Both Linux and BSD clients utilize the GNU package for their stock mv command. The NOW site has a patch set to fix this problem. Also, this patch has been fed back to the FSF.
VFILER CONSIDERATIONS
When run from a vfiler context, (e.g. via the vfiler run command), qtree operates on the concerned vfiler. If a vfiler owns a volume, running qtree in context of that vfiler can create qtrees in that volume, and change the oplocks and security settings of these qtrees. For other qtrees owned by a vfiler (that reside in volumes not owned by the vfiler), the qtree command can be used to change oplocks and security settings of these qtrees.
SEE ALSO
options , quota , quotas , snapmirror , vfiler , file , aggr , vol
- NAME
- SYNOPSIS
- DESCRIPTION
- USAGE
- EXAMPLES
- SINGLE-FILE MV CONSIDERATIONS
- VFILER CONSIDERATIONS
- SEE ALSO
Copyright © 1994-2008 NetApp, Inc. Legal Information
qtree,










































Chris, thanks for the great reading. I’m a noob with NetApp. Just setting up my first FAS2220 to host VMware (NFS) and a SQL database (CIFS). Somebody mentioned I should create a QTree layer first. Will this hamper performance? Doesn’t seem like there’s any downside to QTree’s or am I missing something?
Thanks
QTrees will give you more flexibility as you can then easily use QTree SnapMirror or SnapVault. These both work without QTrees technically, but that might create other complications. No downside of using QTrees, and a couple of upsides (you can set global NTFS / UNIX permissions at the QTree level which is harder to do at the volume level). Definitely no performance overhead.
How do you rename a qtree owned by a vfiler? You can go to “pri set advanced” to run the qtree rename command for the default vfiler (vfiler0) but for other vfilers?
Have you tried doing it from the specific vFiler context?