[DRBD-user] Slow NFS behaviour (0.7.5)
bernd-schubert at web.de
Wed Nov 24 12:34:55 CET 2004
> Yes, every application programmer should be aware of the fact that
> The return of the write() system call means that the data is in the
> OS's buffers, the return of the fsync()/fdatasync() syscall means that
> it is on disk.
please keep in mind that this is not the case with async exported nfs volumes,
> If I log by ssh into my workstation, tar xvzf some.tar.gz, press the reset
> while the operation is in progress, I know that the last files I see
> in my ssh session will not be on the disk when the machines comes up again.
> On the other hand if I do a transaction in my PostgreSQL database I know
> that the new version will be permanent as soon as the prompt returns
> after the commit. Reason: PostgreSQL called fdatasync() on a file
> on the same filesystem . -- The filesystem mount is still async!
> Sane applications know about the Unix/Linux file semantics....
> IMHO is a "sync" mounted filesystem a workaround to fix a broken
Please clearly differentiate between sync/async mount and sync/async NFS
export options, thats really a very big difference.
E.g. a sync mount won't help you on a server failure, if you export async, it
will just slightly slow down the network due to those many NFS commits, but
is not the slighlest way more secure.
There's currently an interesting thread on the nfs mailing list about
async/sync exports, I just cite Trond Myklebust (the linux NFS client
"The problem is the server side "async" option which basically causes
knfsd to ignore COMMIT requests, as well as causing it to fail to
fsync() the directory after file CREATE/LINK/UNLINK/RENAME/...
i.e. it turns of all consistency guarantess on the server."
Physikalisch Chemisches Institut / Theoretische Chemie
e-mail: bernd.schubert at pci.uni-heidelberg.de
More information about the drbd-user