| 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: <47B58EAA.8040405@msgid.tls.msk.ru> Date: Fri, 15 Feb 2008 16:07:54 +0300 From: Michael Tokarev <mjt@....msk.ru> To: Andi Kleen <andi@...stfloor.org>, dm-devel@...hat.com, linux-kernel@...r.kernel.org Subject: Re: [PATCH] Implement barrier support for single device DM devices Alasdair G Kergon wrote: > On Fri, Feb 15, 2008 at 01:08:21PM +0100, Andi Kleen wrote: >> Implement barrier support for single device DM devices > > Thanks. We've got some (more-invasive) dm patches in the works that > attempt to use flushing to emulate barriers where we can't just > pass them down like that. I wonder if it's worth the effort to try to implement this. As far as I understand (*), if a filesystem realizes that the underlying block device does not support barriers, it will switch to using regular flushes instead - isn't it the same thing as you're trying to do on an MD level? Note that a filesystem must understand barriers/flushes on underlying block device, since many disk drives don't support barriers anyway. (*) this is, in fact, an interesting question. I still can't find complete information about this. For example, how safe xfs is if barriers are not supported or turned off? Is it "less safe" than with barriers? Will it use regular cache flushes if barriers are not here? Ditto for ext3fs, but here, barriers are not enabled by default. /mjt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists