On 01/13/2011 02:07 PM, Dr Andrew C Aitchison wrote: > On Thu, 13 Jan 2011, Felix Reinel wrote: > >> Hi, >>> 1) >>> Is there better options I should use to obtain better performance? >>> (e.g. >>> noac will but I would the server to commit to disk and flash should >>> help >>> my speed there) >> Depending on the NFS version you are using, tuning the block sizes might >> help (rsize, wsize). >> The newer versions already have decent blocksizes. >> Configuring the mountpoints with the async option should again speed up >> writes a bit. > > IIRC "async" writes return more quickly but there used to be a > possiblity that the data is not as well protected against disasters > (eg if the server lost power between accepting the request and > flushing to disk). Is this still true ? > NFS version 3 introduces the concept of so called 'safe asynchronous writes'.
From the documentation: 'A Version 3 client can specify that the server is allowed to reply before it has saved the requested data to disk, permitting the server to gather small NFS write operations into a single efficient disk write operation. A Version 3 client can also specify that the data /must/ be written to disk before the server replies, just like a Version 2 write. The client specifies the type of write by setting the stable_how field in the arguments of each write operation to UNSTABLE to request a safe asynchronous write, and FILE_SYNC for an NFS Version 2 style write. Servers indicate whether the requested data is permanently stored by setting a corresponding field in the response to each NFS write operation. A server can respond to an UNSTABLE write request with an UNSTABLE reply or a FILE_SYNC reply, depending on whether or not the requested data resides on permanent storage yet. An NFS protocol-compliant server must respond to a FILE_SYNC request only with a FILE_SYNC reply. Clients ensure that data that was written using a safe asynchronous write has been written onto permanent storage using a new operation available in Version 3 called a COMMIT. Servers do not send a response to a COMMIT operation until all data specified in the request has been written to permanent storage. NFS Version 3 clients must protect buffered data that has been written using a safe asynchronous write but not yet committed. If a server reboots before a client has sent an appropriate COMMIT, the server can reply to the eventual COMMIT request in a way that forces the client to resend the original write operation. Version 3 clients use COMMIT operations when flushing safe asynchronous writes to the server during a close(2) or fsync(2) system call, or when encountering memory pressure.' Felix -- ----------------------------------------------------------------------- Felix Reinel | Web & Systems Administrator Office: D132 ESO | Tel.: +49-89-32006-171 | Address: Fax.: +49-89-32006-677 | European Southern Observatory Mobile: +49-160-2956856 | Karl-Schwarzschild-Strasse 2 E-Mail: [email protected] | D-85748 Garching bei Muenchen, Germany ----------------------------------------------------------------------- http://www.eso.org
signature.asc
Description: OpenPGP digital signature
