From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx141.netapp.com ([216.240.21.12]:22538 "EHLO mx141.netapp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750779AbeCNRdO (ORCPT ); Wed, 14 Mar 2018 13:33:14 -0400 Subject: Re: [RFC 2/7] fs: Add the ZUF filesystem to the build + License To: Andreas Dilger , Boaz Harrosh References: CC: linux-fsdevel , Ric Wheeler , Miklos Szeredi , Steve French , Steven Whitehouse , Jefff moyer , Sage Weil , Jan Kara , Amir Goldstein , Andy Rudof , Anna Schumaker , Amit Golander , Sagi Manole , Shachar Sharon From: Boaz Harrosh Message-ID: Date: Wed, 14 Mar 2018 19:21:03 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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 >