© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
@Kai,
>But you can imagine what happens to fs performance if
>every application does fsyncs after every write or before
>every close. Performance would suffer badly.
Note that the "fsync causes performance problems meme got" started precisely because of ext3's "data=ordered" mode. This is what causes all dirty blocks to be pushed out to disks on an fsync(). Using ext4 with delayed allocation, or ext3 with data=writeback, fsync() is actually quite fast. Again, all modern file systems will be doing delayed allocation, one way or another. Even the much-vaunted ZFS does delayed allocation. So really, the right answer is to use fsync() or fdatasync(), as appropriate.
@Pablomme,
The reason why the write operation is delayed is because of performance. It's always going to give you performance benefits to delay writes for as long as possible. For example, if you end up deleting the file before it ever gets staged out for writing, then you might not need to write it at all. There's a reason why all modern filesystems use delayed allocation as a technique. Now, maybe for desktop applications, we need to have modes that sacrifice performance for better reliability given unreliable device drivers, and applications that aren't explicitly requesting fsync() when they really should.
It comes as an absolute shock to me, for example, that using a system which requires a hard reset whenever you exit "World of Goo", would ever be considered acceptable; I'd use an ATI or Intel chipset before I would accept that kind of reliability. Maybe that's an ivory-tower attitude; I dunno. But for a system which is that unreliable, disabling delayed allocation does make sense. Maybe we can do something such as what r6144 has suggested, where we have a data=alloc-