What is so wrong with a file system honoring the order of operations?
What is so wrong with a file system honoring the order of operations?
Posted Mar 20, 2009 19:06 UTC (Fri) by anton (subscriber, #25547)In reply to: Garrett: ext4, application expectations and power management by dlang
Parent article: Garrett: ext4, application expectations and power management
because providing the ordering that you want would kill performance. it would mean that you could not reorder I/O from the order that the various programs happened to ask for it to something that the storage system can do more efficiently. it would mean that the storage system would (in most cases) not be able to combine separate I/O operations into a smaller number of them.No (to each of these statements). A file system could combine many operations into one large batch, write out the batch in any order and with as few I/O operations as it (or the drive) likes, then commit the whole batch by writing one commit block. That would be efficient. Of course this means that no old block must be overwritten before the commit block is written, but that can be achieved by using a journal or a copy-on-write file system.
And yes, I want that guarantee, I really do, and I don't care if the file system loses 5 seconds or 30 seconds of operations, in case of a crash, but I do care if what it gives me is a state that never logically existed before the crash.