Re: copy_file_range() infinitely hangs on NFSv4.2 over RDMA

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 17.02.2021 23:37, Olga Kornievskaia wrote:
On Tue, Feb 16, 2021 at 5:27 PM Timo Rothenpieler <timo@xxxxxxxxxxxxxxxx> wrote:

On 16.02.2021 21:37, Timo Rothenpieler wrote:
I can't get a network (I assume just TCP/20049 is fine, and not also
some RDMA trace?) right now, but I will once a user has finished their
work on the machine.

There wasn't any TCP traffic to dump on the NFSoRDMA Port, probably
because everything is handled via RDMA/IB.

Yeah, I'm not sure if tcpdump can snoop on the IB traffic. I know that
upstream tcpdump can snoop on RDMA mellanox card (but I only know
about the Roce mode).

I managed to get https://github.com/Mellanox/ibdump working. Attached is what it records when I run the xfs_io copy_range command that gets stuck(sniffer.pcap). Additionally, I rebooted the client machine, and captured the traffic when it does a then successful copy during the first few minutes of uptime(sniffer2.pcap).

Both those commands were run on a the same 500M file.

But I recorded a trace log of rpcrdma and sunrpc observing the situation.

To me it looks like the COPY task (task:15886@7) completes successfully?
The compressed trace.dat is attached.

I'm having a hard time reproducing the problem. But I only tried
"xfs", "btrfs", "ext4" (first two send a CLONE since the file system
supports it), the last one exercises a copy. In all my tries your

I can also reproduce this on a test NFS share from an ext4 filesystem.
Have not tested xfs yet.

xfs_io commands succeed. The differences between our environments are
(1) ZFS vs (xfs, etc) and (2) IB vs RoCE. Question is: does any
copy_file_range work over RDMA/IB. One thing to try a synchronous

It works, on any size of file, when the client machine is freshly booted (within its first 10~30 minutes of uptime).

copy: create a small file 10bytes and do a copy. Is this the case
where we have copy and the callback racing, so instead do a really
large copy: create a >=1GB file and do a copy. that will be an async
copy but will not have a racy condition. Can you try those 2 examples
for me?

I have observed in the past, that the xfs_io copy is more likely to succeed the smaller the file is, though I did not make out a definite pattern.

I did some bisecting on the number of bytes, and came up with the following:
A 2097153 byte sized file gets stuck, while a 2097152(=2^21) sized one still works.

It's been stable at that cutoff point for a while now, so I think that's actually the point where it starts happening, and different behaviour I saw in the past was an issue in my testing.

Not sure how useful tracepoints here are. The results of the COPY
isn't interesting as this is an async copy. The server should have
sent a CB_COMPOUND with the copy's results. The process stack tells me
that COPY is waiting for the results (waiting for the callback). So
the question is there a problem of sending a callback over RDMA/IB? Or
did the client receive it and missed it somehow? We really do need
some better tracepoints in the copy (but we don't have them
currently).

Would you be willing to install the upstream libpcap/tcpdump to see if
it can capture RDMA/IB traffic or perhaps Chunk knows that it doesn't
work for sure?

Managed to get ibdump working, as stated above.

Attachment: sniffer.pcap
Description: Binary data

Attachment: sniffer2.pcap
Description: Binary data

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux