cp from NFS to ZFS hung in "fifoor"

[Mikhail T.]

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

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