Andi Kleen wrote: > > Is there a reason why this isn't being done other than performance? > > One reason against it is that in many (but not all) setups to guarantee > reaching the platter you have to disable the write cache, and at least > for consumer level hard disks disk vendors generally do not recommend > doing this because it significantly lowers the MTBF of the disk. I think the MTBF argument is a bit spurious, because guaranteeing it reaches the platter with all modern disks is possible, with the appropriate kernel changes, and does not require the write cache to be disabled. TBH, I think the reason is it's simply never been implemented. There are other strategies for mitigating data loss, after all, and filesystem structure is not at risk; barriers are fine for that. Right now, you have the choice of 'disable write cache' or 'fsync flushes sometimes but not always, depending on lots of factors'. The option 'fsync flushes always, write cache enabled' isn't implemented, though most hardware supports it. Btw, on Darwin (Mac OS X) it _is_ because of performance that fsync() doesn't issue a flush to platter. It has an fcntl(F_FULLSYNC) which is documented to do the latter. -- 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
