On Monday, December 15, 2014 3:59:29 pm Rick Macklem wrote: > Mehmet Erol Sanliturk wrote: > > On Mon, Dec 15, 2014 at 1:24 AM, Gerrit Kühn > > <gerrit.ku...@aei.mpg.de> > > wrote: > > > > > > Hi all, > > > > > > I ran into some weird issue here last week: > > > I have an NFS-Server for storage and diskless booting (pxe / nfs > > > root) > > > running under FreeBSD. The clients are running Gentoo Linux. Some > > > time > > > ago, I replaced the server, going from a HDD-based storage array > > > (ZFS) > > > under FreeBSD 8.3 to an SSD-based array under FreeBSD 10-stable (as > > > of > > > February this year - I know this needs updates). > > > > > > Only now I recognized that this somehow appears to have broken some > > > of my > > > Gentoo ebuilds that do not install cleanly anymore. They complain > > > about > > > "soiled libtool library files found" and "insecure RUNPATHs" in the > > > installation stage of shared libs. > > > > > > I was not able to find any useful solution for this in the Net so > > > far. > > > However, I was able to verify that this is somehow an issue with > > > the nfs > > > server by plugging in a USB-drive into the diskless clients and > > > mounting > > > this as /var/tmp/portage (the directory structure where Gentoo's > > > ebuilds > > > are compiled). This makes the error messages go away, and > > > everything works > > > again (like it did before the server update). > > > > > > Are there any suggestions what might be causing this and how to fix > > > it? > > > > > > > > > cu > > > Gerrit > > > > > > > > > > > > With respect to information given in your message , may pure guess is > > the > > following : > > > > > > When a client generates a file in NFS server , it assumes that > > everything > > is written into the file . > > The next step ( reading the generated file ) starts , BUT the file is > > NOT > > completely written into disk yet , > > therefore it reads an incomplete file which causes errors in the > > client . > > > Well, not exactly. The NFS client chooses whether or not the written > data must be committed to stable storage (disk) right away via a flag > argument on the write. It is up to the client to keep track of what has > been written and if the FILE_STABLE flag wasn't set, must do a separate > Commit RPC to force the data to stable storage on the server. > It is also up to the NFS client to keep track of the file's size while > it is being grown, since the NFS server's size may be smaller until > the data gets written to the server. > Also, note that he didn't see the problem with FreeBSD8.3, which would > have been following the same rules on the server as 10.1. > > What I suspect might cause this is one of two things: > 1 - The modify time of the file is now changing at a time the Linux > client doesn't expect, due to changes in ZFS or maybe TOD clock > resolution. (At one time, the TOD clock was only at a resolution > of 1sec, so the client wouldn't see the modify time change often. > I think it is now at a much higher resolution, but would have to > look at the code/test to be sure.)
No, it's still only a second resolution on FreeBSD by default. You can make this precise on the NFS server by setting the vfs.timestamp_precision sysctl to 3. We should probably be using that by default for at least server-class systems. -- John Baldwin _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
