On Mar 13, 2018, at 11:17 AM, Boaz Harrosh <boazh@netapp.com> wrote:
> 
> 
> This adds the ZUF filesystem-in-user_mode module
> to the fs/ build system.
> 
> Also added:
> 	* fs/zuf/Kconfig
> 	* fs/zuf/module.c - This file contains the LICENCE of zuf code base
> 	* fs/zuf/Makefile - Rather empty Makefile with only module.c above
> 
> I add the fs/zuf/Makefile to demonstrate that at every
> patchset stage code still compiles and there are no external
> references outside of the code already submitted.
> 
> Off course only at the very last patch we have a working
> ZUF feeder
> 
> Signed-off-by: Boaz Harrosh <boazh@netapp.com>
> +/*
> + * Version rules:
> + *   This is the zus-to-zuf API version. And not the Filesystem
> + * on disk structures versions. These are left to the FS-plugging
> + * to supply and check.
> + * Specifically any of the API structures and constants found in this
> + * file.
> + * If the changes are made in a way backward compatible with old
> + * user-space, MINOR is incremented. Else MAJOR is incremented.
> + *
> + * We believe that the zus Server application comes with the
> + * Distro and should be dependent on the Kernel package.
> + * The more stable ABI is between the zus Server and its FS plugins.
> + * Because of the intimate relationships in the zuf-core behavior
> + * We would also like zus Server to be signed by the running Kernel's
> + * make crypto key and checked before load because of the Security
> + * nature of an FS provider.
> + */
> +#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).


Cheers, Andreas