[lustre-devel] [PATCH 000/622] lustre: sync closely to 2.13.52

NeilBrown neilb at suse.de
Tue Apr 28 20:32:31 PDT 2020


On Tue, Apr 28 2020, James Simmons wrote:

>> > These patches need to be applied to the lustre-backport branch
>> > starting at commit a436653f641e4b3e2841f38113620535e918dd3f.
>> 
>> Hi James et al,
>>  I applied these patches on top of a43.... then added the other patches I
>>  had an looked for difference to my previous tree.
>>  I found a bunch of improvements you had made, plus some errors that
>>  came through your patches, plus some other problems that already
>>  existed...
>> 
>>  I've then added patches from OpenSFS master to get uptodate.
>>  The result is not on my github tree in the lustre/lustre branch.  It
>>  has 226 patches on top of the set you posted.
>> 
>>  git log 823691f8d49c~3..823691f8d49c
>> 
>>  will show you some error I fixed, in case you are interested.
>
> I grabbed those fixes and applied them to my tree. Its nice to see my 
> tree, your tree, and the OpenSFS branch starting to merge. I updated
> my tree to the same OpenSFS commit as your tree and have started to look 
> at difference. I noticed the sync with my tree didn't exactly match up. 
> You lost a few changes. Some of the major changes missing are
>
> 1) LU-9679 llite: Discard LUSTRE_FPRIVATE()
>    OpenSFS hash : 9e5cb57addbb5d7bc1596096821ad8dcac7a939b

Thanks.  I've also added

2bea4a7a3706 LU-5432 fld: don't loop forever on bogus FID sequences
2f66b4903516 LU-7768 fld: Do not retry fld request
8d4ef45e0780 LU-7524 fld: fld_clientlookup retries next target

which I had found by comparison myself but not applied yet.

> 2) LU-13274 uapi: make lnet UAPI headers C99 compliant 
>    OpenSFS hash: 742897a967cff5be53c447d14b17ae405c2b31f2

I have that...
Commit 619f523e5c36 ("lustre: uapi: make lnet UAPI headers C99 compliant")

What did I miss?

>
> Also their are some kmem_cache bugs that causes several of the sanity
> test to crash the client. I need to do more comparing of our tree and
> sort out the changes that haven't landed or been pushed to the OpenSFS 
> branch to figure out these regressions. I can easily see in the 4 to 8 
> weeks all the patches in your tree to land to OpenSFS as well as my tree. 
> So we could sort everything out once everything has landed. I need to 
> pull a few changes you have as well to my tree for cleanups like for the 
> fid layer that seem to have gotten lost. Mostly likely from people doing
> cleanups while in staging.
>
> Now for some important info. I noticed sanity test failing recently
> which I tracked down to me not updating my lustre utilities. This is
> going to be a problem so to make it painless I created a few patches
> to enable building the lustre utilies only against the linux
> client. If you apply the following patches:
>
> https://review.whamcloud.com/#/c/38369
> https://review.whamcloud.com/#/c/38370

This one:
 LU-12511 build: don't use OpenSFS UAPI headers with --disable-modules

doesn't seem like a good thing.  It implies that the UAPI headers in
OpenSFS give different results than the ones in Linux.
If this is true - we need to fix it. The UAPI needs to be stable.

Do you know what the important differences are.

> https://review.whamcloud.com/#/c/38105
> https://review.whamcloud.com/#/c/36603
> https://review.whamcloud.com/#/c/34954
>
> Now for 33603 patch it exposes a regression with LSOM and 
> open_by_handle_at(). This patch removes the need for dot_lustre which is 
> broken anyways for submounts (filesets). The 'dot_lustre' in the UAPI 
> header is used for general utilites as well as the kernel server code. 
> Since it had no use in the linux client it was nuked :-) Instead of 
> restoring it we can resolve the LSOM issues for 33603 patch.
>
> Once you apply the above patches just run:
>
> sh autogen.sh
> ./configure --disable-modules --disable-server
> make rpms
>
> and you will have proper rpms to use with the linux client. I recommend
> after updating the linux client to update your utilities as well 
> everytime.

Thanks from the thorough response.  I'll keep this in mind when I next
refresh my linux test setup.

Thanks,
NeilBrown
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20200429/cb1f1b9a/attachment.sig>


More information about the lustre-devel mailing list