Thread (8 messages) 8 messages, 2 authors, 2024-06-17

Re: reservation errors during fstests on pNFS block

From: Christoph Hellwig <hch@infradead.org>
Date: 2024-06-14 18:26:18

On Fri, Jun 14, 2024 at 05:46:21PM +0000, Chuck Lever III wrote:
quoted
Reservation means another node has an active reservation on that LU.
There are only two accessors of the LUN: the NFS server and
the NFS client running the test. That's why these errors are
a little surprising to me.
You can create registrations from userspace, and some cluster managers
do that.  But none of that should happen for a default setup.
quoted
When pNFS layout access fails we fall back to normal access through the
MDS, so this is expected.
Expected, OK. From a usability standpoint, error messages like
this would probably be alarming to administrators. I plan to
convert the printk's and dprintk's in the NFSD layout code into
trace points, but that doesn't help the messages emitted by the
block and SCSI drivers. Ideally this should be less noisy.
Well, they really should be alarming because the admin configured
a block layout setup and it did not work as expected.  So it should
ring alarm bells.
quoted
Is generic/069 that first test that failed when doing a full xfstests
run?
Yes, it's a full run. generic/069 is the first test where there
are remarkable system journal messages (ie, PR errors), though
there are a few subsequent tests that are also whinging.
Interesting.  Normally only the server actually reserves the LU,
the clients just register.  And something went wrong here and only
for these tests.
quoted
Do you see LAYOUT* ops in /proc/self/mountstats for the previous
tests?
generic/013 is known to generate layout recalls, for example,
so there is layout activity during the test run.
Ok.  The other thing would be to run blktrace on the client and
see that it shows I/O.  But all this sounds like the tests in
general work, but something is up with generic/069.

generic/069 just does O_APPEND writes, so I can't see what
would be so special about it.
I can go back and try reproducing with just generic/069 and
tcpdump as a first step. Is there a way I can tell that the
PR errors are not reporting a possible data corruption?
xfstests in general does data verifycation to check for data integrity,
so we should not rely on kernel messages.

I'm a bit busy right now, but I'll try to reproduce this locally next
week.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help