[lkml]   [2019]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Regression in 5.1.20: Reading long directory fails
>>>>> "BF" == J Bruce Fields <> writes:

BF> Looks like that's db531db951f950b8 upstream. (Do you know if it's
BF> reproduceable upstream as well?)

Yes, it's reproducible up in the 5.3.0 RCs as well.

However, while trying to do some further bisecting I ran into an odd
problem. Now kernels which were previously working (i.e. 5.1.19 and
older) are returning errors, but at a different file count. This only
gives me more questions. And so, just to be absolutely sure that there
isn't some weird server issue involved, I'm going to try to schedule a
reboot of the relevant server.

BF> Maybe it depends on having names of the right length to place some
BF> bit of xdr on a boundary. I wonder if it'd be possible to reproduce
BF> just by varying the name lengths randomly till you hit it.

I know I can't reproduce with loads of short names, and with relatively
long names as well (using sha256sum as filename generator).

BF> No clever debugging ideas off the top of my head, I'm afraid. I
BF> might start by patching the kernel or doing some tracing to figure
BF> out exactly where that EIO is being generated?

If I had any idea how to do that, I happily would. I'm certainly
willing to learn. At least I can run strace to see where ls bombs:

getdents64(5, 0x7fc13afaf040, 262144) = -1 EIO (Input/output error)

bcodding on IRC mentioned that is a rather large count. Does make me
wonder if the server is weirding out and sending the client bogus data.
Certainly a server reboot, or maybe even just unmounting and remounting
the filesystem or copying the data to another filesystem would tell me
that. In any case, as soon as I am able to mess with that server, I'll
know more.

_ J<

 \ /
  Last update: 2019-08-28 20:29    [W:0.077 / U:2.300 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site