compiling on nfs directories

[Rick Macklem]

Gerrit Kuhn wrote:
> On Mon, 15 Dec 2014 15:59:29 -0500 (EST) Rick Macklem
> <rmacklem at uoguelph.ca> wrote about Re: compiling on nfs directories:
> 
> 
> RM> Also, note that he didn't see the problem with FreeBSD8.3, which
> would
> RM> have been following the same rules on the server as 10.1.
> RM>
> RM> What I suspect might cause this is one of two things:
> RM> 1 - The modify time of the file is now changing at a time the
> Linux
> RM>     client doesn't expect, due to changes in ZFS or maybe TOD
> clock
> RM>     resolution. (At one time, the TOD clock was only at a
> resolution
> RM>     of 1sec, so the client wouldn't see the modify time change
> often.
> RM>     I think it is now at a much higher resolution, but would have
> to
> RM>     look at the code/test to be sure.)
> RM> 2 - I think you mention this one later in your message, in that
> the
> RM>     build might be depending on file locking. If this is the
> case,
> RM>     trying NFSv4, which does better file locking, might fix the
> RM>     problem.
> 
> Meanwhile I have googled around a bit more, and one of the few
> reasons
> other people see the error messages I see appears to be a broken
> clock that
> makes "make" recompile stuff on the installation stage. As I was
> already
> wondering why compilation took longer than I had actually expected, I
> may
> be seeing something similar (still need to look into that), although
> my
> clock is fine (but time stamps on the NFS might be messed up somehow
> like
> you mention above under "1").
avg@ just MFC'd a one line ZFS patch (the one I vaguely remembered before).
It is r275401 in head:
https://svnweb.freebsd.org/base/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c?r1=274337&r2=275401

and appears to fix a problem with mtime being updated.
This patch might be worth a try?
(You could email avg at freebsd.org for more information on it.)

rick

> 
> RM> Gerrit, I would suggest that you do "nfsstat -m" on the Linux
> client,
> RM> to see what the mount options are. The Linux client might be
> using
> RM> NFSv4 already.
> 
> This is what it says about my nfs-root:
> 
> ---
> pt-nds ~ # nfsstat -m
> / from 192.168.32.253:/tank/diskless/nds
>  Flags:
>  rw,relatime,vers=3,rsize=4096,wsize=4096,namlen=255,hard,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.32.253,mountvers=3,mountproto=tcp,local_lock=all,addr=192.168.32.253
> ---
> 
> This is what I set up for pxe-booting:
> 
> ---
> label gentoo-cs2
>   menu label linux-3.8.13-gentoo-2
>   kernel bzImage-3.8.13-gentoo-2
>   append ip=dhcp root=/dev/nfs rw
>   nfsroot=192.168.32.253:/tank/diskless/nds,nolock,tcp,v3
>   rootdelay=15
> ---
> 
> 
> So I definitely run "nfsv3" and "nolock". I remember trying to use
> nfsv4 on the diskless machines some years ago, but back then it was
> not ready for prime time.
> 
> RM> Also, avoid "soft, intr" especially if you are using NFSv4, since
> these
> RM> can cause slow server response to result in a failure of a
> read/write
> RM> when it shouldn't fail, due to timeout or interruption by a
> signal.
> 
> There is "hard" in there as a default option. However, I might try
> turning on locking (I regarded it as superfluous up to now as I have
> only one client using the filesystem).
> 
> RM> If you could find out more about what causes the specific build
> failure
> RM> on the Linux side, that might help.
> 
> As I said above, I have some hints that indicate something might be
> wrong with timestamps, but I still need to dig deeper into that.
> 
> RM> If you can reproduce a build failure quickly/easily, you can
> capture
> RM> packets via "tcpdump -s 0 -w <file> host <client-hostname>" on
> the
> RM> server and then look at it in wireshark to see what the server is
> RM> replying when the build failure occurs. (I don't mind looking at
> a
> RM> packet trace if it is relatively small, if you email it to me as
> an
> RM> attachment.)
> 
> I can reproduce it 100%, but it only happens on the installation
> stage, after having compiled the whole stuff. So I don't know if I
> will be able to produce a dump of reasonable size that contains the
> issue, but I'll try.
> 
> RM> ps: I am not familiar with the Linux mount options, but if it has
> RM>     stuff like "nocto", you could try those.
> 
> The manpage has the following:
> 
> ---
>        cto / nocto    Selects  whether  to  use  close-to-open cache
>        coherence
>                       semantics.  If neither option is specified (or
>                       if cto is
>                       specified),  the  client uses close-to-open
>                       cache coher-
>                       ence semantics. If the nocto option  is
>                        specified,  the
>                       client  uses  a non-standard heuristic to
>                       determine when
>                       files on the server have changed.
> 
>                       Using the nocto option may improve performance
>                       for read-
>                       only  mounts, but should be used only if the
>                       data on the
>                       server changes only occasionally.  The DATA AND
>                       METADATA
>                       COHERENCE  section discusses the behavior of
>                       this option
>                       in more detail.
> ---
> 
> 
> So "cto" appears to be the default and is probably what is used right
> now. I'll put "nocto" on my list of things to try (although the
> description is not really that incouraging... :-).
> 
> 
> cu
>   Gerrit
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to
> "freebsd-net-unsubscribe at freebsd.org"
>