> It is sad to see people attack Ted here for simply pointing out bugs in applications.
I don't see anyone attacking Ted. I see people arguing against the idea that zeroing out files is a
good quality for a filesystem to have.
> But, when it comes to the behaviour of one file system in one of its modes which was
> masking incorrect usage of the API, we quickly revert to screaming bloody murder and
> asking for more hand holding.
So perhaps ext5 should erase the entire directory if it's had any entries added or removed since
the last time someone called fsync on the directory fd? Or how about *never* writing any data to
disk unless you've called fsync on the file, its parent directory, and all parent directories up to
> That seems like the real problem to me. If I ask for fsync on _my_ file, why on earth
> does the file system flush the lot out? Shouldn't _that_ be fixed instead?
Yes, it would be nice, but it's a performance issue, not a data-loss issue.
Presumably at some point someone will figure out how to make a filesystem such that it can
avoid writing out metadata updates related to data which is not yet on disk, without actually
forcing out unrelated data just because you need to write out a metadata update in a different
part of the filesystem.