On Mar 14, 2018, at 11:21 AM, Boaz Harrosh <boazh@xxxxxxxxxx> wrote: > > On 13/03/18 22:16, Andreas Dilger wrote: > <> >>> + */ >>> +#define ZUFS_MINORS_PER_MAJOR 1024 >>> +#define ZUFS_MAJOR_VERSION 1 >>> +#define ZUFS_MINOR_VERSION 0 >> >> I haven't really been following this development, but my recommendation >> would be to use feature flags (e.g. at least __u64 compat, __u64 incompat) >> for the API and separately for the disk format, rather than using version >> numbers. This makes it clear what "version" relates to a specific feature, >> and also allows *removal* of features if they turn out to be a bad idea. >> With version numbers you can only ever *add* features, and have to keep >> support for every old feature added. >> >> Also, having separate feature flags allows independent development of new >> features, and doesn't require that feature X has to be in version N or it >> will break for anyone using/testing that feature outside of the main tree. >> >> This has worked for 25 years for ext2/3/4 and 15 years for Lustre. ZFS >> has a slightly more complex feature flags, distinguishing between features >> that _could_ be used (i.e. enabled at format time or by the administrator), >> and features that _are_ used (with a refcount). That avoids gratuitous >> incompatibility if some feature is enabled, but not actually used (e.g. >> ext4 files over 2TB), and also allows removing that incompatibility if the >> feature is no longer used (e.g. all > 2TB files are deleted). >> > > Yes thank you. As you can see at this RFC stage I have not even put any > code to enforce the ABI/API versioning yet. Exactly because I don't like > it as you explained. I will think about your suggestion and see. This is > not on disk stuff. This is more the communication channel between > ZUF<=>ZUS. Though there are a couple on disk stuff. > (The on disk things are all hidden from here inside the usermode FS plugin) > > The thing is that I want to work a system with the distro's that the > ZUF<=>ZUS ABI can freely change, by forcing the zusd package be dependent > on the kernel package. And it be signed by the Kernel's make key. Meaning > it will only run against the kernel it was compiled against. That is a major pain, and even the distros are doing things like weak module symbol versions so that external kernel modules do not need to be rebuilt for every minor kernel update. > And keep the stable ABI with feature and versioning between the > ZUSD<=>zusFS-plugin(s) > We'll have to see > > Thanks > Boaz Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP
