Am 30.03.2012 21:36, schrieb Adrian Chadd: > Let me tell you a story. > > Someone decided that ext4 could have a decent speed up if it > implemented the posix standard for not flushing files on close(). > After all, if you needed it to be guaranteed to be written to disk, > you would call a flush routine first, before you called close(). > > So they did this. > > Then people testing out ext4 discovered that upon crash, their > kde/gnome profiles were corrupted. > > Why? Because KDE/Gnome authors hadn't ever called flush before > close(), and they weren't the only ones. They didn't read the > standard, they only used the system and fixed bugs whenever their > system behaved against their expectations. They didn't notice that the > system was being different from the standard. > > Guess what ext4 did? :)
ext4 sprouted an option (auto_da_alloc, when used with the proper data journalling option data=ordered) to support buggy software. Note that ext4 isn't pioneering the "fsync() required" semantics here, there are other precedents of "0-blocks in files after crash" in Linux file systems, such as XFS. I'm oblivious to the current ext4 defaults WRT these semantics (and I haven't looked at vanilla kernels for a while anyways---distros might have changed default settings). _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
