| |||||||||||||
An alternative to the application barrier() callAn alternative to the application barrier() callPosted Sep 20, 2009 5:22 UTC (Sun) by runekock (subscriber, #50229)In reply to: An alternative to the application barrier() call by anton Parent article: POSIX v. reality: A position on O_PONIES
> Fortunately writes on the file system level can be merged across file system barriers, resulting in few barriers that have to be passed to the block device level.
But what about eliminating repeated writes to the same place? Take this contrived example:
repeat 1000 times:
A COW file system may well be able to merge the writes, but it would require a lot of intelligence for it to see that most of the writes could actually be skipped. And a traditional file system would be even worse off.
(Log in to post comments)
An alternative to the application barrier() call Posted Sep 20, 2009 18:38 UTC (Sun) by anton (guest, #25547) [Link] 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).
|
|||||||||||||