From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl0-f66.google.com ([209.85.160.66]:33548 "EHLO mail-pl0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752280AbeCMUQh (ORCPT ); Tue, 13 Mar 2018 16:16:37 -0400 Received: by mail-pl0-f66.google.com with SMTP id c11-v6so464446plo.0 for ; Tue, 13 Mar 2018 13:16:37 -0700 (PDT) From: Andreas Dilger Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_7EB9431C-5025-488E-B68D-EBDC7D1F9AAC"; 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: Tue, 13 Mar 2018 14:16:30 -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=_7EB9431C-5025-488E-B68D-EBDC7D1F9AAC Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Mar 13, 2018, at 11:17 AM, Boaz Harrosh 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 > +/* > + * 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 --Apple-Mail=_7EB9431C-5025-488E-B68D-EBDC7D1F9AAC 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+AFAlqoMZ4ACgkQcqXauRfM H+D7AQ//fKygUwhK6Hqra6NM9wxQfskNOALkW26JhNPkRXuVCkGE+SsOq2XlN5b2 yMy7+i8Gk503MTJRQpZBXbFgCDDaCYkBzOAZkCjUuOp18Ldw8sdxf1eVCZVgl6B6 A+M9bmRmAQQrJxr/dHH8ghXpgeZ8INzNjIhFFGMiUyDa3+kZffFhjDB0xue241q/ 0fUmlSoFodUQufMjAgU9STT73EB1UPYRa4kR54oAInduZaZIVgaRfSFjIUQ7/F7R gJQSabTVDSz5XQJbKMd6Sk13e97MOt3bvJvAui/t/55nSZlQYDoiyP+YSWEKpRNm l0WB81kLSs8+NtfDlomBPH36K1LCPe/0kF6Gq8NQzjfHtuLOjtlo8+EWqbUPT7bY Cup0zggV5DMepHkntTYXkSPKJHJYH3U7puE0siwf2Cjz8HEE0CFFocun20mUskYj UGSwR/CmiGxsrmeunvhnfmdj3+jV2UH0HFTQJjFbWXNXgeAoYwX7vHd0sfgqUeAd iDyl8buSPFHpneBmPaef4c4c3DsJ3TgW68laJhBXdZTYYAOkHyU3tkQ6wB0SZ7MK U+90D/jzM4S4vaCgUXdq9c8f1NHX9F7s7U7o6I0zJCTNQnfzHYtF4uEpTZ2WPe4h rB2VfSuFgbrZLiKDd8/ScV5E4ByoqC8yvh8D/5hUmne2CbgfkVc= =Hl// -----END PGP SIGNATURE----- --Apple-Mail=_7EB9431C-5025-488E-B68D-EBDC7D1F9AAC--