cp from NFS to ZFS hung in "fifoor"

[Rick Macklem]

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
> 
I just tried a trivial test (using a fairly old FreeBSD9 and a pretty recent
FreeBSD-head) and wasn't able to reproduce the problem.
For my tests, "ls -l" in the NFS client showed "p" and the "cp -R" worked.
I only have UFS file systems and tested with those.

I can only think of a couple of explanations:
1 - ZFS didn't fill the v_type in as FIFO. The NFS server uses the v_type
    field to determine it is a fifo and not the high order bits of va_mode
    (the S_IFMT bits). I don't have ZFS to test with.
2 - You somehow used an NFSv2 mount. (NFSv2 didn't have support for FIFOs,
    if I recall correctly.)
    You can check your mount options, including which version is in use via
    "nfsstat -m" unless you have a pretty old system.

If you have a UFS file system on the NFS server, maybe you could try exporting
that and run a test, to see if it happens for a UFS export?

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"