Wandering Thoughts archives


The problem of ZFS pool and filesystem version numbers

ZFS pools and filesystems have version numbers for the straightforward reason; it lets ZFS augment or (carefully) change the on-disk storage format to add new features. Old versions of ZFS will know that they shouldn't touch a pool with a new version because they don't understand all of its metadata; new versions of ZFS will know that some pools can't have new metadata written to them and so on. All of this is very conventional.

In light of my previous entry on the several OS options for getting ZFS, it's occurred to me that this nice scheme has a little problem. To put it simply: if you have ZFS pool at version 55 is that the Solaris ZFS version 55, the Illumos version 55, or the FreeBSD version 55?

Right now it is always the Solaris version N, because both Illumos and FreeBSD stopped at the last OpenSolaris ZFS pool version. But this situation may not last forever; someday the Illumos people may well want to make a pool change that is not in Solaris, and they may also not want to reimplement some changes that created new Solaris pool version numbers. In fact the Illumos people may not be able to reimplement some Solaris changes; since Solaris is closed source they don't have source code, and Oracle may not release full documentation for the disk format and so on (or the changes may involve patented technology).

To make the problem worse, ZFS version numbers are a sequence where support for version N implies support for everything in version N-1, N-2, and so on. This means that even if Oracle was feeling friendly it can't just allocate a ZFS pool version for some Illumos change, because it would mean that when Oracle wanted to use version N+1 for its next change it would need to support the Illumos version N change.

The root cause of this issue is that when Sun designed ZFS version numbers, they intended there to be a single authority for them, ie Sun itself, and a single sequence of features. This single authority and sequence is viable only so long as there is only one version of ZFS, Sun's Oracle's. But once ZFS forks, which is what it effectively has done, there is no single authority any more and all of this explodes.

Sidebar: the problem for Illumos

In theory Illumos can half-solve this problem by defining a new ZFS property for the Illumos ZFS version; Illumos pools would then have a base ZFS version number of something or other (possibly set at the last official ZFS version that Illumos supports) plus their own Illumos version number. However, the problem with this is stopping Solaris systems from improperly importing Illumos ZFS pools, because after all Solaris doesn't know anything about the new Illumos version property.

I think that the only way out for Illumos is for them to create their own Illumos pool version property and then set the basic ZFS version to some implausibly high value, one that Solaris should never reach. Solaris systems will give the wrong error report, but there's only so much you can do.

(Illumos systems would always report the Illumos version number as the pool version number.)

solaris/ZFSPoolVersionProblem written at 00:34:41; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.