When to create a ZFS filesystem?

Comments Off on When to create a ZFS filesystem?

Someone named “Edward M” posted on the freebsd-questions mailing list a question of when should we create a ZFS filesystem. I didn’t reply to any of the messages, but I decided to write this post expressing my view.

In short, whenever a part of the filesystem hierarchy exhibits different characteristics, create one or more ZFS filesystems for that particular subtree.

In more detail:

  1. Separating the hierarchy into many ZFS filesystems can make backup a lot easier. Although most backup systems allow you to specify exclude lists, listing only the important filesystems might save you some precious backup space and time.
  2. On the same note, if you allow your users to create their own filesystem through ZFS Delegated Administration, then your users must inform the personnel in charge of the backup system what filesystems to back up. (Maybe we should suggest the illumos people erect a new ZFS property allowing us to specify our desire for backup of the files stored in a particular subtree of the pool. However, this would in turn require every valid backup system to be aware of such a property and act accordingly. The use of user-properties might be a compromise.)
  3. Configuration files are usually text files and easily compressable. Thus, /usr/local/etc would be a perfect candidate as a separate ZFS filesystem. Mind you, this is not recommended at all for /etc as those files must be present within the dataset specified by the zpool bootfs property.
  4. Source code are also highly compressable, and thus should /usr/src and /usr/ports be separate filesystem with compression enabled. The subtrees /usr/ports/distfiles and /usr/ports/packages should be created as ZFS filesystems without any compression applied, as the files stored in these locations are compressed by nature.
  5. MySQL databases write their data in chunks of 16 KiB. Thus, it makes sense not only making /var/db/mysql a separate ZFS filesystem, you should also set the ZFS recordsize property to 16K.
  6. PostgreSQL databases write their data in chunks of 8 KiB. Similarly, /usr/local/pgsql should be a separate ZFS filesystem with the ZFS recordsize property set to 8K.
  7. Maybe some of your data is so precious that it would not only make sense to create a separate filesystem for these files, you might also consider raising the ZFS copies property to 2 or even 3 for added redundancy within the storage pool.
  8. Sometimes you might want to limit the amount of storage space used by a particular ZFS filesystem and its children by setting an appropriate value for the ZFS quota property. If you want to limit the amount of storage space used only by a particular ZFS filesystem, set the appropriate value for the ZFS refquota property.
  9. It might be necessary to guarantee some amount of storage space for a particular ZFS filesystem and possibly its children, and then you would turn to the ZFS reservation and refreservation properties. These properties are used in the same manner as with the ZFS quota and refquota properties.
  10. If you’re planning on creating snapshots for only a subset of the hierarchy, create a separate ZFS filesystem at the appropriate branchpoint.
  11. If you later add more disks and want all your files to take advantage of the new disks, then create a new filesystem with a similar name and placement, move your files from the old filesystem to the new one, delete the old filesystem, and rename the new filesystem to match the old filesystem’s name.
  12. Finally, if possible, separate your user’s files from the system’s files by using separate zpools.