cp from NFS to ZFS hung in "fifoor"

Rick Macklem rmacklem at uoguelph.ca
Sun Nov 29 14:42:12 UTC 2015


Mikhail T. wrote:
> On 28.11.2015 17:41, Jilles Tjoelker wrote:
> > Although cp -R will normally copy a fifo by calling mkfifo at the
> > destination, it may open one if a regular file is replaced with a fifo
> > between the time it reads the directory and it copies that file.
> 
> The sole fifo under /home here was mi/.licq/licq_fifo, created in 2003.
> I echoed something into it (on the NFS-client side) and the cp-process
> resumed.
> 
> I then performed a simple test:
> 
>  1. Create a fifo in an NFS-exported directory and try to copy it with
>     the -R flag
>     mi at narawntapu:/cache/src (792) mkfifo /green/tmp/test
>     mi at narawntapu:/cache/src (793) cp -Rpn /green/tmp/test /tmp/
>     mi at narawntapu:/cache/src (794) ls -l /tmp/test
>     prw-r--r--  1 mi  wheel  0 29 лис 00:05 /tmp/test
>     The above worked fine.
>  2. Now, when I try to do the same thing via an NFS mount, I get the
>     same hang in fifoor:
>     root at aldan:ports/x11/kde4 (475) cp -Rpn /green/tmp/test /tmp/
>     load: 0.42  cmd: cp 38299 [fifoor] 1.15r 0.00u 0.00s 0% 1868k
> 
> So, the good news is, this is not ZFS' fault. The bad news is, there is
> still a bug... Unless, of course, this is some known "feature" of the
> NFS... Compare, for example, how stat(1) describes the same named pipe
> from both machines:
> 
>     Local FS:
>     92 74636334 prw-r--r-- 1 mi wheel 0 0 "Nov 29 00:05:51 2015" "Nov 29
>     00:05:51 2015" "Nov 29 00:05:51 2015" "Nov 29 00:05:51 2015" 16384 0
>     0 /green/tmp/test
>     NFS-client:
>     973143811 74636334 ?rw-r--r-- 1 mi wheel 4294967295 0 "Nov 29
>     00:05:51 2015" "Nov 29 00:05:51 2015" "Nov 29 00:05:51 2015" "Dec 31
>     18:59:59 1969" 16384 0 0 /green/tmp/test
> 
The other thing you could do is capture packets for the "ls -l" from the NFS
client:
   tcpdump -s 0 -w fifo.pcap host <nfs-server>
run on the client while doing the "ls -l" should be sufficient. (Doing it just
after mounting will avoid any attribute cache hit.)

You could then look at the fifo.pcap in wireshark (or email it to me as an
attachment and I can look) and see if the file type attribute is FIFO.
(If it isn't, then the NFS server is broken somehow.)

rick

> That question-mark in the node-type (instead of the "p") is, I guess,
> what confuses cp into trying to read from it instead of creating a fifo.
> Should I file a PR? Thank you!
> 
>     -mi
> 
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"


More information about the freebsd-stable mailing list