| |||||||||||||
An alternative to the application barrier() callAn alternative to the application barrier() callPosted Sep 20, 2009 18:38 UTC (Sun) by anton (guest, #25547)In reply to: An alternative to the application barrier() call by runekock Parent article: POSIX v. reality: A position on O_PONIES For a copy-on-write file system that example would be easy: Do all the writes in memory (in proper order), and when the system decides that it's time to commit the stuff to disk, just do a commit of the new logical state to disk (e.g., by writing the first block each of file A and file B and the respective metadata to new locations, and finally a commit sector that makes the new on-disk state visible. An update-in-place file system (without journal) would indeed have to perform all the writes in order to have the on-disk state reflect one of the logical POSIX states at all times (assuming that there are no repeating patterns in the two values that are written; if there are, it is theoretically possible to skip the writes between two equal states).
(Log in to post comments)
|
|||||||||||||