Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hello Philipp, > 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, see below. > > 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 > application. 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 maintainer) here: "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." Cheers, Bernd -- Bernd Schubert Physikalisch Chemisches Institut / Theoretische Chemie Universität Heidelberg INF 229 69120 Heidelberg e-mail: bernd.schubert at pci.uni-heidelberg.de