| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20120514105148.GG5353@quack.suse.cz> Date: Mon, 14 May 2012 12:51:48 +0200 From: Jan Kara <jack@...e.cz> To: Asdo <asdo@...ftmail.org> Cc: Jan Kara <jack@...e.cz>, linux-ext4@...r.kernel.org Subject: Re: ext4 barrier on SCSI vs SATA? 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@...e.cz> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists