Marc:
There is currently an active discussion about filesystem semantics in Linux; it appears that sometimes, maybe, perhaps, just possibly, applications should call fsync somewhere:
http://lwn.net/Articles/323464/
And see other stories in Linux Weekly News. I just searched the lib directory of gambit, and I didn't find any active fsync's (there were two in IF 0'd code). Does that mean that I'm going to lose data when I use the file system as a poor man's database with gambit? (Actually, it's not so poor, it's quite nice to be able to read "database" information in S-expression format.)
Just a heads up.
Brad
Afficher les réponses par date
Date: Wed, 18 Mar 2009 23:56:42 -0400 From: Bradley Lucier lucier@math.purdue.edu
There is currently an active discussion about filesystem semantics in Linux; it appears that sometimes, maybe, perhaps, just possibly, applications should call fsync somewhere:
http://lwn.net/Articles/323464/
And see other stories in Linux Weekly News. I just searched the lib directory of gambit, and I didn't find any active fsync's (there were two in IF 0'd code). Does that mean that I'm going to lose data when I use the file system as a poor man's database with gambit? (Actually, it's not so poor, it's quite nice to be able to read "database" information in S-expression format.)
Applications should call fsync when they cannot correctly proceed until they can guarantee that their files have been written to permanent storage. Applications should *not* call fsync if this is not required. Many applications have a much lighter requirement -- after writing new data, they want either the old file or the new file in permanent storage, provided that what is permanently stored is not a corrupted intermediate state. To do this they write the new data to a file linked at a temporary pathname, and then rename it to overwrite the link at the permanent pathname. Ext4 can corrupt the files in permanent storage by reordering these operations, so that the link is renamed in permanent storage before the new data are written, leaving only a truncated file and neither new nor old data.
If you want to avoid corrupting data when your machine crashes or the power fails, assuming that the crash is not so catastrophic that the permanent storage is irrecoverably destroyed, then use the procedure I described, and avoid buggy file systems such as ext4 and XFS. Fsync is a red herring.
(It would be nice if Gambit provided fsync for those applications that do need to guarantee that files have been written to permanent storage before they can proceed, but this is unrelated to the recent ext4 kerfuffle.)