From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f171.google.com ([209.85.192.171]:38795 "EHLO mail-pf0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750715AbeCOEVO (ORCPT ); Thu, 15 Mar 2018 00:21:14 -0400 Received: by mail-pf0-f171.google.com with SMTP id d26so2382809pfn.5 for ; Wed, 14 Mar 2018 21:21:14 -0700 (PDT) From: Andreas Dilger Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_98AF778E-B5E4-4C1E-863A-BA7D30C5EF0D"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [RFC 2/7] fs: Add the ZUF filesystem to the build + License Date: Wed, 14 Mar 2018 22:21:07 -0600 In-Reply-To: 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 To: Boaz Harrosh References: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: --Apple-Mail=_98AF778E-B5E4-4C1E-863A-BA7D30C5EF0D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 14, 2018, at 11:21 AM, Boaz Harrosh wrote: >=20 > 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 >>=20 >> 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. >>=20 >> 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. >>=20 >> 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). >>=20 >=20 > 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<=3D>ZUS. Though there are a couple on disk stuff. > (The on disk things are all hidden from here inside the usermode FS = plugin) >=20 > The thing is that I want to work a system with the distro's that the > ZUF<=3D>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<=3D>zusFS-plugin(s) > We'll have to see >=20 > Thanks > Boaz Cheers, Andreas --Apple-Mail=_98AF778E-B5E4-4C1E-863A-BA7D30C5EF0D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEDb73u6ZejP5ZMprvcqXauRfMH+AFAlqp9LQACgkQcqXauRfM H+D0mw//TLYbv/PBA2buvmIA4f0DLCOf9QWn7yvjssGS0rTJfUNFdENlOkgnb6Hk DEXxHvh43ytN6oJDVfhe/6s8z3TomMmTxbHZ3JZt61b2xaDoDL8sIYn05cdZSYBF UuEMwUr4sLlEZm7NtPBNi37MG0rMRoZKLjPkkDtvpa3CHNAy9kTieIoiOShz0gu/ rttCmhhE3Rk/Hd4R9CtRBX3airKCiztkoZ5CfyKBpdQs0p275CPEHzrnURPEGisp FB1+o2YQ0OIONfzBW3bgX1+SMfLCfbJ+1xHZUqQLvTZ/M1hrH/cag7HSMkwu6kn9 8zD4ZiFGzQWB+DaMc9puHR4HTTOCEgM9xCaFrzQS582Q3qXfuRlRfVp3rwCxK8kc h8vfp6p5yTSDKm3INPJEh+Kxcu+ZD9GXmtJKqYNXNntJLnSzpW/K7uGuarNKwAqK dDxFADKR+E0pGIzUDajtdnzTBmWJHTPRQ2uKP0bWrY0U/gBUdJd6XFf9FDRLT7PU 5quFY/p+lx1oQF8sdTmnyYtuBDuvf4HDd5//CU7Gl+7Rs20eDHTzbiPt+Gn61Xvo hzawfX5B0cMhlO3FbOw2sbyBQ0LA1QuFE4YRqSRVHtvb3hG6K3yQz6AUq/6MIAHi B21zjsSVgTEM4cHYgPknbO7cym9lHbE1PKVQVUJlV4HIiTiPlC0= =0RgT -----END PGP SIGNATURE----- --Apple-Mail=_98AF778E-B5E4-4C1E-863A-BA7D30C5EF0D--