Features that I wish ZFS had

September 5, 2007

This is not counting features that Sun has already said they are going to put in someday, like the ability to remove vdevs from a ZFS pool. The motivation for many of these wishes is good long term storage management, something that ZFS is currently weak at.

  • the ability to migrate a filesystem from storage pool to storage pool (on the same system) without user-visible downtime or lockups. In theory this ought to be doable, since ZFS is abstracting everything anyways.

  • the ability to control and change what vdevs a filesystem will use (or occupy), or at least what sort of vdevs they will or won't use. This would make it easier to have filesystems with different levels of reliability needs in the same general storage pool, especially when those needs change.

    (To a certain extent this isn't needed if there is transparent storage pool to storage pool migration of filesystems.)

  • the ability to turn an existing directory into a sub-filesystem, or an existing sub-filesystem back into an ordinary directory, without losing the contents in either case.

    An example may help illustrate why I want this. The natural grouping of people's home directories around here is by group; everyone in one group gets clumped into one top-level directory. However, every so often a professor will want to do something like NFS-export their home directory to their personal workstation.

    The theoretical ZFS answer is to make everyone's home directory into a ZFS filesystem right up front. However, this leads to a profusion of NFS mounts; it would be nicer if we could defer turning someone's home directory into a filesystem until we really needed to.

  • an option so that if you NFS mount a given ZFS filesystem, you automatically get all of the sub-filesystems that you have NFS access permission for without having to mount them explicitly.

    The problem with using ZFS the way that Sun wants you to in an NFS world is that you wind up with thousands of NFS mounts in even a modest environment. But this is hard to manage, especially when you create and delete filesystem-worthy entities all the time. Many of these entities will have the same NFS export permissions; they are being created for other things, like quota control or separate snapshots or so on. It would be nice to be able to treat them as a unit, so you could mount the top level filesystem and didn't have to care about the details of all of the sub-filesystems.

    (For example, we should really have one ZFS filesystem per user home directory, and another ZFS filesystem for their public_html subdirectory, so that we can export it to the web server but deny the web server general home directory permissions, and things proliferate from there.)

Disclaimer: to the best of my knowledge, ZFS doesn't have and isn't planned to have these features; however, I would be happy to be wrong.

Written on 05 September 2007.
« Why syndication feed readers ignore an entry's 'last updated' time
Where to find specifications on HTTP POST behavior »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Sep 5 00:44:46 2007
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.