Valerie Aurora Henson wrote: > All that being said, I'd be thrilled to have fine-grained fsync(). Me too. Ted raises a very good point that fine-grained fsync will not be used by most applications, and they expect good behaviour automatically on crashes without it (which is imho reasonable to ask for). A lot of apps and scripts go wrong if the disk is full too. I've seen more truncated files from that than from system crashes. I think both events are so rare that most of the time nobody cares. They're corner cases. Let's face it, nearly every shell script which edits files in a specific order (see also "make") will see inconsistencies following a system crashes. But the thing is: certain core packages where reliability is a requirement will use whatever mechanisms are available. Every mail transport and database engine seems to get this right - or try their best given limitations of the OS - it's their job to care. Those are widely used by other apps. Let's face it, like most other authors, if powerfail-robustness were that important to us on linux-kernel, barriers would never have been off by default on ext3, and fsync would always have emitted barriers. The thing is: you _can_ expect certain core packages, used by a large number of apps, to make use of whatever features work well. Make those reliable and you've solved a big chunk of the problem. Make the core packages able to perform well at the same time, and a few more apps will use them instead of their own implementations. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
