Date: Sun, 29 Nov 2015 09:38:24 -0500 (EST) From: Rick Macklem <rmacklem@uoguelph.ca> To: "Mikhail T." <mi+thun@aldan.algebra.com> Cc: Jilles Tjoelker <jilles@stack.nl>, freebsd-fs <freebsd-fs@freebsd.org>, stable@freebsd.org Subject: Re: cp from NFS to ZFS hung in "fifoor" Message-ID: <1842140450.110568454.1448807904673.JavaMail.zimbra@uoguelph.ca> In-Reply-To: <565A8A3E.205@aldan.algebra.com> References: <5659CB64.5020105@aldan.algebra.com> <20151128224101.GA8470@stack.nl> <565A8A3E.205@aldan.algebra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
>=20
> 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.
>=20
> I then performed a simple test:
>=20
> 1. Create a fifo in an NFS-exported directory and try to copy it with
> the -R flag
> mi@narawntapu:/cache/src (792) mkfifo /green/tmp/test
> mi@narawntapu:/cache/src (793) cp -Rpn /green/tmp/test /tmp/
> mi@narawntapu:/cache/src (794) ls -l /tmp/test
> prw-r--r-- 1 mi wheel 0 29 =D0=BB=D0=B8=D1=81 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@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
>=20
> 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:
>=20
> 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
>=20
I just tried a trivial test (using a fairly old FreeBSD9 and a pretty recen=
t
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 export=
ing
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!
>=20
> -mi
>=20
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1842140450.110568454.1448807904673.JavaMail.zimbra>