Differences from Traditional Filesystems

Before continuing further with ZFS, there are some important topics that differ significantly from traditional filesystems. Understanding these key differences will help reduce confusion when using traditional tools to interact with ZFS.

The following sections are provided in this chapter.

• 3.1 ZFS Filesystem Granularity

• 3.2 Space Accounting

• 3.3 Out of Space Behavior

• 3.4 Mounting Filesystems

• 3.5 Volume Management

• 3.6 ACLs

3.1 ZFS Filesystem Granularity

Historically, filesystems were constrained to one device so that the filesystems themselves were constrained to the size of the device. Creating and recreating traditional filesystems because of size constraints are time-consuming and sometimes difficult. Traditional volume management products helped manage this process.

Because ZFS filesystems are not constrained to specific devices, they can be created easily and quickly like directories. They grow automatically within the space allocated to the storage pool.

Instead of creating one filesystem, such as /export/home, to manage many user subdirectories, you can create one filesystem per user. In addition, ZFS also provides a filesystem hierarchy so that it is easy to set up and manage many filesystems by applying properties that can be inherited by filesystems contained within the hierarchy.

For an example of creating a filesystem hierarchy, see 2.4 Creating a Filesystem Hierarchy.

3.2 Space Accounting

ZFS is based on a concept of pooled storage. Unlike typical file systems, which are mapped to physical storage, all ZFS file systems in a pool share the available storage in the pool. So the available space reported by utilities like df may change even when the file systems is inactive, as other file systems in the pool consume or release space. Note that maximum file system size can be limited using quotas (see 5.6.1 Setting Quotas), and space can be guaranteed to a file system using reservations (see 5.6.2 Setting Reservations). The user experience of this model is very similar to the NFS experience when multiple directories are mounted from the same file systems (consider /home).

All metadata in ZFS is allocated dynamically. Most other file systems pre-allocate much of their metadata. As a result, there is an immediate space cost at file system creation for this metadata. This also means that the total number of files supported by the file systems is predetermined. Since ZFS allocates its metadata as it needs it, there is no initial space cost, and the number of files is limited only by the available space. The output from the df -g command must be interpreted differently for ZFS than other file systems: the total files reported is only an estimate based on the amount of storage available in the pool.

ZFS is a transactional file system. Most file system modifications are bundled into transaction groups and committed to disk asynchronously. Until they are committed to disk, they are termed pending changes. The amount of space used, available, and referenced by a file or filesystem does not take into account pending changes. Pending changes are generally accounted for within a few seconds. Even committing a change to disk using fsync(3c) or O_SYNC does not necessarily guarantee that the space usage information will be updated immediately.

3.3 Out of Space Behavior

File system snapshots (see Chapter 6, ZFS Snapshots and Clones) are "cheap and easy" to make in ZFS. It is anticipated that they will be common in most ZFS environments. The presence of snapshots can cause some unexpected behavior when attempting to free up space. It is generally expected that, given appropriate permissions, one can always remove a file from a full file system, and that this action results in more space becoming available in the file system. However, if the file to be removed exists in a snapshot of the file system, then there is no space gained from the file deletion. The blocks making up the file continue to be referenced from the snapshot. In fact, the file deletion can end up consuming more disk space, since a new version of the directory will need to be created to reflect the new state of the namespace. This means that one can get an unexpected ENOSPC or EDQUOT when attempting to remove a file.

3.4 Mounting Filesystems

ZFS is designed to reduce complexity and ease administration. For example, in existing systems it is necessary to edit /etc/vfstab every time a new filesystem is added. ZFS has eliminated this need by automatically mounting and unmounting filesystems according to properties of the dataset. There is no need to add ZFS entries to the /etc/vfstab file.

For more information on mounting and sharing filesystems, see 5.5 Mounting and Sharing File Systems.

3.5 Volume Management

As described in 1.1.1 Pooled Storage, ZFS eliminates the need for a separate volume manager. ZFS operates on raw devices, however, so it's possible to create a storage pool comprised of logical volumes (either software or hardware). This is not a recommended configuration, as ZFS works best when using raw physical devices. Using a logical volumes may sacrifice performance and/or reliability, and should be avoided.

3.6 ACLs

Previous versions of Solaris supported an ACL implementation that was primarily based on the POSIX ACL draft specification. The POSIX-draft based ACLs are used to protect UFS files. A new ACL model that is based on the NFSv4 specification is used to protect ZFS files.

The main differences of the new ACL model are as follows:

• Based on the NFSv4 specification and are similar to NT-style ACLs.

• Much more granular set of access privileges.

• Set and displayed with the chmod and ls commands rather than the setfacl and getfacl commands.

• Richer inheritance semantics for designating how access privileges are applied from directory to subdirectories, and so on.

For more information about using ACLs with ZFS files, see Chapter 7, Using ACLs to Protect ZFS Files.