Date: Mon, 15 Dec 2014 07:04:34 -0800 From: Mehmet Erol Sanliturk <m.e.sanliturk@gmail.com> To: =?UTF-8?B?R2Vycml0IEvDvGhu?= <gerrit.kuehn@aei.mpg.de> Cc: freebsd-net@freebsd.org Subject: Re: compiling on nfs directories Message-ID: <CAOgwaMs%2BYLUoLSHDsu6BOYgwr_oi09xNk9yOnSNYjjXqaiDCQQ@mail.gmail.com> In-Reply-To: <20141215102429.bcbae18ae63464a7254fc580@aei.mpg.de> References: <20141215102429.bcbae18ae63464a7254fc580@aei.mpg.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 15, 2014 at 1:24 AM, Gerrit K=C3=BChn <gerrit.kuehn@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 work= s > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOgwaMs%2BYLUoLSHDsu6BOYgwr_oi09xNk9yOnSNYjjXqaiDCQQ>