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 . In FreeBSD NFS server , there is NOT ( or I could NOT be able to find ) a facility to store written data immediately into disk . NFS server is collecting data up to a point ( number of bytes ) and then writing it to disk , during this phase ( whether the NFS server is busy or not ) is not important ) . With this structure , the tasks which a program writes a small number of bytes to be read by another program can not be processed by a NFS server only . I did not try "locking in NFS server" : If this route is taken , then it is necessary to adjust the clients for such periods to wait that NFS server has removed the lock which themselves can continue ( Each such read requires a waiting loop without generating an error message about unavailable data and termination . ) . In Linux NFS server , there is an option to immediately write the received data into disk . This is improving the above situation considerable but not completely solving the problem ( because during reads of data , data in cache is NOT concatenated to the data in disk ) . Another MAJOR problem is that , the NFS server is NOT concatenating data in cache to data in disk during reads : This defect is making NFS server useless for , let's say "real time" , applications used concurrently or as a single one by the clients without using another "Server" within NFS server . In your case , during software builds , a step is using the previously generated files : In local disk , writing and reading are sequential , in the sense that written data is found during reading . In NFS server this is not the case . With respect to my knowledge obtained from messages in FreeBSD mailing lists about making a possibility to read data immediately after it is written into NFS server is NOT available . Thank you very much . Mehmet Erol Sanliturk _______________________________________________ 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"
