> I was reading a book on filesystem design, and came across the
> following scary quote:
>
> "The main difference between ext2 and FFS is that ext2 makes no
> guarantee about consistency of the file system or whether an operation
> is permanently on the disk when the file system call completes.
> [...] This consistency model is not without drawbacks and may not be
> appropriate at all for some applications. Because ext2 makes no
> guarantee about the order of operations and when they are flushed to
> disk, it is conceivable (although unlikely) that later modifications
> to the file system would be recorded on disk but earlier operations
> would not be. Although the file system consistency check would
> ensure that the file system is consistent, the lack of ordering on
> operations can lead to confused applications or, even worse, crashing
> applications because of the inconsistencies in the order of
> modifications to the file system."
> _Practical File System Design_, Dominic Giampaolo, p. 36
Hmmm ... If we remove the first sentence that claims FFS does the right
thing but EXT2 does not, this sounds right in theory. AFAIK, common UNIX
O/Ses donnot guarantee File System objects fine IO ordering. Just allowing
synchronous vs asynchonous writes is very poor and everything should be
handled synchronously by the FS in order to really guarantee consistency.
This obviously would break performances dramatically.
At SCSI IO level, it is possible to ask the device server for ordering
requirement when providing it with severall IOs. A tagged command can
be queued with SIMPLE_TAG, ORDERED_TAG, HEAD_TAG. This allow the device
firmware to optimize its caching strategy without breaking user wanted
ordering of actual IO operations.
If we imagine some ideal O/S that provides equivalent ordering services
for its cache handling and that will ensure physical ordering matches
the cache ordering by using appropriate ordering tags at physical IO
level, then it would be possible to implement an EXT2 FS that does the
right thing, as well as any other File System by the way.
Gerard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/