Re: [RFC 2/7] fs: Add the ZUF filesystem to the build + License

From: Boaz Harrosh <boazh@netapp.com>
To: Andreas Dilger <adilger@dilger.ca>, Boaz Harrosh <boazh@netapp.com>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Ric Wheeler <rwheeler@redhat.com>,
	Miklos Szeredi <mszeredi@redhat.com>,
	Steve French <smfrench@gmail.com>,
	Steven Whitehouse <swhiteho@redhat.com>,
	Jefff moyer <jmoyer@redhat.com>, Sage Weil <sweil@redhat.com>,
	Jan Kara <jack@suse.cz>, Amir Goldstein <amir73il@gmail.com>,
	Andy Rudof <andy.rudoff@intel.com>,
	Anna Schumaker <Anna.Schumaker@netapp.com>,
	Amit Golander <Amit.Golander@netapp.com>,
	Sagi Manole <sagim@netapp.com>,
	Shachar Sharon <Shachar.Sharon@netapp.com>
Subject: Re: [RFC 2/7] fs: Add the ZUF filesystem to the build + License
Date: Wed, 14 Mar 2018 19:21:03 +0200	[thread overview]
Message-ID: <c2133d8c-dbfa-726d-6da0-9f1dc9e702e3@netapp.com> (raw)
In-Reply-To: <A2ED64D0-5B7F-425D-98BD-FE40C5650524@dilger.ca>

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.

And keep the stable ABI with feature and versioning between the
ZUSD<=>zusFS-plugin(s)
We'll have to see

Thanks
Boaz
> 
> Cheers, Andreas
> 