| 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: <200903122012.45607.nickpiggin@yahoo.com.au> Date: Thu, 12 Mar 2009 20:12:45 +1100 From: Nick Piggin <nickpiggin@...oo.com.au> To: Francis Moreau <francis.moro@...il.com> Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Andrew Morton <akpm@...ux-foundation.org> Subject: Re: Question regarding concurrent accesses through block device and fs On Thursday 12 March 2009 20:00:38 Francis Moreau wrote: > On Thu, Mar 12, 2009 at 9:22 AM, Nick Piggin <nickpiggin@...oo.com.au> wrote: > > Ignore details like crashes, direct IO and coherency between data > > mappings and buffercache where things get a bit hairy, and it's just a > > writeback cache. The last thing you write to some location will be what > > you get back if you read from that location -- regardless of whether it > > is dirty or clean or not present when you ask for it (and has to be read > > from disk). > > Well yes but I was wondering in the special where the kernel crash or > the power supply is down how the kernel is minimizing the risk of file > system inconsistency. Hence my questions about metadata handling. Well, journalling filesystems, other filesystems can do synchronous metadata updates (write through) which can help too. There is really nothing that the generic pagecache/buffercache code does to try to handle this because it is far to filesystem specific. -- 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