Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   NeilBrown <neilb@suse.com>
To:     James Simmons <jsimmons@infradead.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        devel@driverdev.osuosl.org,
        Andreas Dilger <andreas.dilger@intel.com>,
        Oleg Drokin <oleg.drokin@intel.com>
Date:   Fri, 09 Feb 2018 12:39:18 +1100
Cc:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Lustre Development List <lustre-devel@lists.lustre.org>,
        wang di <di.wang@intel.com>,
        James Simmons <jsimmons@infradead.org>
Subject: Re: [PATCH 41/80] staging: lustre: lmv: separate master object with master stripe
In-Reply-To: <1471378773-24590-42-git-send-email-jsimmons@infradead.org>
References: <1471378773-24590-1-git-send-email-jsimmons@infradead.org> <1471378773-24590-42-git-send-email-jsimmons@infradead.org>
Message-ID: <87r2pvkkl5.fsf@notabene.neil.brown.name>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
        micalg=pgp-sha256; protocol="application/pgp-signature"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tue, Aug 16 2016, James Simmons wrote:

>=20=20
> +static inline bool
> +lsm_md_eq(const struct lmv_stripe_md *lsm1, const struct lmv_stripe_md *=
lsm2)
> +{
> +	int idx;
> +
> +	if (lsm1->lsm_md_magic !=3D lsm2->lsm_md_magic ||
> +	    lsm1->lsm_md_stripe_count !=3D lsm2->lsm_md_stripe_count ||
> +	    lsm1->lsm_md_master_mdt_index !=3D lsm2->lsm_md_master_mdt_index ||
> +	    lsm1->lsm_md_hash_type !=3D lsm2->lsm_md_hash_type ||
> +	    lsm1->lsm_md_layout_version !=3D lsm2->lsm_md_layout_version ||
> +	    !strcmp(lsm1->lsm_md_pool_name, lsm2->lsm_md_pool_name))
> +		return false;

Hi James and all,
 This patch (8f18c8a48b736c2f in linux) is different from the
 corresponding patch in lustre-release (60e07b972114df).

In that patch, the last clause in the 'if' condition is

+           strcmp(lsm1->lsm_md_pool_name,
+                     lsm2->lsm_md_pool_name) !=3D 0)

Whoever converted it to "!strcmp()" inverted the condition.  This is a
perfect example of why I absolutely *loathe* the "!strcmp()" construct!!

This causes many tests in the 'sanity' test suite to return
=2DENOMEM (that had me puzzled for a while!!).
This seems to suggest that no-one has been testing the mainline linux
lustre.
It also seems to suggest that there is a good chance that there
are other bugs that have crept in while no-one has really been caring.
Given that the sanity test suite doesn't complete for me, but just
hangs (in test_27z I think), that seems particularly likely.


So my real question - to anyone interested in lustre for mainline linux
=2D is: can we actually trust this code at all?
I'm seriously tempted to suggest that we just
  rm -r drivers/staging/lustre

drivers/staging is great for letting the community work on code that has
been "thrown over the wall" and is not openly developed elsewhere, but
that is not the case for lustre.  lustre has (or seems to have) an open
development process.  Having on-going development happen both there and
in drivers/staging seems a waste of resources.

Might it make sense to instead start cleaning up the code in
lustre-release so as to make it meet the upstream kernel standards.
Then when the time is right, the kernel code can be moved *out* of
lustre-release and *in* to linux.  Then development can continue in
Linux (just like it does with other Linux filesystems).

An added bonus of this is that there is an obvious path to getting
server support in mainline Linux.  The current situation of client-only
support seems weird given how interdependent the two are.

What do others think?  Is there any chance that the current lustre in
Linux will ever be more than a poor second-cousin to the external
lustre-release.  If there isn't, should we just discard it now and move
on?

Thanks,
NeilBrown


--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEG8Yp69OQ2HB7X0l6Oeye3VZigbkFAlp8+8YACgkQOeye3VZi
gbmBKQ/+N2KBAw2lRurkIXFnMflCyFJ0tYIWK9PpF+rYiPB4t5XDzGdTJ8+hk9iM
9jVr39LMliYEWCq3AZkSYFCeCg2GgE3jLUw9waE1EjEyhwOxCkcnrD3E42W2r9YK
PN9lren4hLelbFRhTO9xCTKT9wQKI1/JzN/Tbaas2hVH0UwQ8gfB572fhCFz1TnV
DG47NnBwjm52gjcq6imOLRooy6hfuw2n638F9Ibz1/c3WQbgEWi0CgO/0bjeCMQV
j9f4NiWapYIlZsg5+mpKZkEgEum5XCYZtsUXVbQLM2LoEMuNI5658VEurE/jqvzd
muEyXYSusWeOc+AJZT67PMMfmy3BHCwS9qMAgGMaMtVKWnEuGztSCNjJs/LckLuC
s9icTPStymLIvmZKT+hIUz3H48FWqDh354ALu2TDDq7kH822VnSWoz1fgP6BZ80T
PCq2LIVoNvG/5M8xInyzvyMgaGsGamKVEIoNJsqpsn3/Xgh+rayLX5b/FRhkt2Aq
u4hRSNXFSNQAr6SDrq1He/WkigyAJ41XA/bnC6gzdnGTUsA9SZs6e6rRq08jKmzw
Myt6RUZ3+EhPir/iv/CDbw6/1rvq7eDngNpmWPNkwW/FTEiI0+b/4p6bqjDHQY1r
T1hfXYtzR3pCxiuEJeRT8GLAz+oFgKFFN+LVu4nMgLQK2Ks9DG4=
=OIfh
-----END PGP SIGNATURE-----
--=-=-=--