On Mon 14-05-12 12:33:03, Asdo wrote: > On 05/14/12 11:02, Jan Kara wrote: > >>However the flush was always available (I think), in fact databases > >>would not corrupt (not even above ext4 nobarrier, above a raid5 > >>without barriers) if fsync was called at proper times. > > This is not true. Both cache flushes and barriers were implemented by > >the same mechanism in older kernels. Thus if the device did not properly > >propagate the barrier capability, then fsync did not provide any guarantees > >in case of power failure (if there are volalile write caches in the storage > >device). > > Oh! Thanks I had not realized this. > > So, if barrier IS provided by the underlying blockdevice but > filesystem is nevertheless mounted as nobarrier (as an explicit > option) would database flushes (fsync) for files on THAT filesystem > work properly or not? If you have volatile write caches, they would not. nobarrier option means: "I *know* I don't need cache flushes for data integrity and I want maximum performance." Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
