What a qtree is
A qtree is a logically defined file system that can exist as a special subdirectory of the root directory within either a traditional volume or a FlexVol volume. You can create up to 4995 qtrees per volume.
There is no maximum limit for the storage system as a whole. You can create qtrees for managing and partitioning your data within the volume.
In general, qtrees are similar to volumes. However, they have the following key differences:
• Snapshot copies can be enabled or disabled for individual volumes but not for individual qtrees.
• Qtrees do not support space reservations or space guarantees.
There are no restrictions on how much disk space can be used by the qtree or how many files can exist in the qtree.
Qtree options
You must specify the following when creating a qtree: a name for the qtree and the volume in which the qtree resides. By default, the security style of a qtree is the same as that for the root directory of the volume. By default, oplocks are enabled for each qtree. If you disable oplocks for the entire storage system, oplocks are not set even if you enable oplocks on a per-qtree basis.
Related concepts
Qtree name restrictions on page 105 About the CIFS oplocks setting on page 106 Security styles on page 106
When to use qtrees
Qtrees enable you to partition your data without incurring the overhead associated with a volume.
You might create qtrees to organize your data, or to manage one or more of the following factors:
quotas, backup strategy, security style, and CIFS oplocks setting.
The following list describes examples of qtree usage strategies:
• Quotas
You can limit the size of the data used by a particular project, by placing all of that project's files into a qtree and applying a tree quota to the qtree.
• Backups
You can use qtrees to keep your backups more modular, to add flexibility to backup schedules, or to limit the size of each backup to one tape.
• Security style
If you have a project that needs to use NTFS-style security, because the members of the project use Windows files and applications, you can group the data for that project in a qtree and set its security style to NTFS, without requiring that other projects also use the same security style.
• CIFS oplocks settings
If you have a project using a database that requires CIFS oplocks to be off, you can set CIFS oplocks to off for that project's qtree, while allowing other projects to retain CIFS oplocks.
Qtree name restrictions
Qtree names can be no more than 64 characters in length. In addition, using some special characters in qtree names, such as commas and spaces, can cause problems with other Data ONTAP
capabilities, and should be avoided.
The following characters should be avoided in qtree names:
• Space
Spaces in qtree names can prevent SnapMirror updates from working correctly.
• Comma
Commas in qtree names can prevent quotas from working correctly for that qtree, unless the name is enclosed in double quotation marks.
Related concepts
Qtree options on page 104
Security styles
Storage systems running Data ONTAP operating system supports different types of security styles for a storage object. By default, the security style of a qtree is the same as that for the root directory of the volume.
UNIX The user's UID and GID, and the UNIX-style permission bits of the file or directory determine user access. The storage system 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 storage system 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 storage system generates and stores a set of UNIX-style permission bits that are at least as restrictive as the Windows NT permissions.
The storage system 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 storage system 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 set-ACL request to the file, the file's security style is changed to NTFS. If a file currently uses the NTFS security style and an NFS user sends a set-permission request to the file, the file's security style is changed to UNIX.
Related concepts
Qtree options on page 104
About the CIFS oplocks setting
Usually, you should leave CIFS oplocks (opportunistic locks) on for all volumes and qtrees. This is the default setting. However, you might turn CIFS oplocks off under certain circumstances.
CIFS oplocks enable the redirector on a CIFS client in certain file-sharing scenarios to perform client-side caching of read-ahead, write-behind, and lock information. A client can then work with a file (read or write it) without regularly reminding the server that it needs access to the file. This improves performance by reducing network traffic.
You might turn CIFS oplocks off on a volume or a qtree under either of the following circumstances:
• You are using a database application whose documentation recommends that CIFS oplocks be turned off.
• You are handling critical data and cannot afford even the slightest data loss.
Otherwise, you can leave CIFS oplocks on.
For more information about CIFS oplocks, see the CIFS section of the Data ONTAP File Access and Protocols Management Guide for 7-Mode.
Related concepts
Qtree options on page 104