Ts'o: Delayed allocation and the zero-length file problem
Posted Mar 13, 2009 15:44 UTC (Fri) by forthy
In reply to: Ts'o: Delayed allocation and the zero-length file problem
Parent article: Ts'o: Delayed allocation and the zero-length file problem
"POSIX allows this" is an anal point. Like "the C standard allows
this". This is not what standard documents are about. I'm working in a
standard committee, and standards are about compromises between different
implementations who all have different design goals. If you design a file
system, it is your task to define those parts left out by the standard.
Do you want it fast, do you want it robust, or do you want it compatible
with some cruft out there for 25 years (like FAT)? A robust file system
has to preserve a consistent state of the file system in case of a
crash - and POSIX defines what consistent is: no reordering of operations
allowed. The real solution therefore is log-structured file system with
COW. Ok, so wait for btrfs.
But in the meantime, ext4 could just delay metadata writes as well,
and make sure that at these sync points it does not commit meta data
until it also has written the data out. The bug here is that ext4
writes "commit" to a metadata update even though data updates issued
prior to this metadata update are still pending.
to post comments)