ZFS v5000 and Feature Flags

[brbubba]

Two questions...

First, when upgrading to 9.1 presumably it won't auto-update the pool to v5000? You'd have to do it via command line "zpool upgrade -a".

Second, feature flags still confuse the hell out of me. Basically I understand it as allowing different developers to roll out different features independently of each other without versioning consideration. But how would this effect cross compatibility? To me, the beauty of ZFS was that I could just plop an array out of FreeNAS and have it up and running in linux or opensolaris, etc in a matter of minutes. So it seems that if one developer implements a feature flag, let's say LZ4 compression, and you enable it, then if you port to another platform that feature flag may not work any longer and possibly make your pool inaccessible on the new platform??? Would disabling LZ4 on the old platform suddenly make it compatible with v5000 on the new platform??? Also say FreeBSD is implementing their LZ4 feature flag and ZFSonLinux implements their LZ4 feature flag, are they always guaranteed to be cross compatible or are we opening up a jungle of incompatible feature flags?

 

[dlavigne]

1. Correct.

2. That is not my understanding of feature flags. Have you read something different to give you this understanding?

AFAIK, the big number bump was to differentiate the open source version from the closed source version and that the open source devs/projects who are interested in ZFS are working together: http://freebsdnow.blogspot.com/2013/07/freebsd-92-feature-highlight-zfs-lz4.html.

 

[brbubba]

http://blog.delphix.com/csiden/files/2012/01/ZFS_Feature_Flags.pdf

What happens when Delphix uses ZFS version 30 for a new async destroy
feature and Nexenta uses ZFS version 30 for RAIDZ 4?

Trying to import a pool with unsupported features in the "active" state prints
detailed error information listing the incompatible features

Gives features the option to "undo" their on disk changes changing the
feature's state from "active" back to "enabled", making the pool
compatible with an older software version again (some features may
not be able to do this)

Feature flags does not help merge code for two conflicting features
○ What happens when Delphix uses compression algorithm #14 for one
algorithm and Joyent uses it for another?
○ What happens when Delphix uses the 59th bit in the block pointer as a
flag and Joyent uses bits 56-63 to store an enum value?
○ For now we need to be careful, in the future we hope to have standard
ways of handling this (the same way feature flags gives us a way to
handle version numbers)

This is older so maybe it has been amended, but it's a wee bit concerning if there could be incompatible feature flags floating around out there. In practice, it seems unlikely to happen, but it doesn't really alleviate my confusion.

Thanks, I'll be sure to tread lightly...

 

[dlavigne]

I think the discussions that came out of that paper were to make sure that those scenarios don't happen. Will be interesting to see how closely the interested open source projects continue to work together on open source ZFS.

 

[brbubba]

Yeah, you're right dlavigne. I watched the youtube presentation for that powerpoint and while it could happen, it seems highly improbable. It sounded like the only people that would be doing this would be some custom development at a massive corporate array where they wanted to write in their own custom feature flags.

 

[cyberjock]

I doubt there's any corporation with the resources to add their own flags either. Look at what's happened since ZFS has gone closed source 3-4 years ago. Lots of promised features but as far as I know there's been no development that's made it to public release that's worth mentioning.