lkml.org 
[lkml]   [2009]   [Mar]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux 2.6.29


On Wed, 25 Mar 2009, Ric Wheeler wrote:
>
> One concern with doing this above the file system is that you are not in the
> context of a transaction so you have no clean promises about what is on disk
> and persistent when. Flushing the cache is primitive at best, but the way
> barriers work today is designed to give the transactions some pretty critical
> ordering semantics for journalling file systems at least.
>
> I don't see how you could use this approach to make a really robust, failure
> proof storage system, but it might appear to work most of the time for most
> people :-)

You just do a write barrier after doing all the filesystem writing, and
you return with the guarantee that all the writes the filesystem did are
actually on disk.

No gray areas. No questions. No "might appear to work".

Sure, there might be other writes that got flushed _too_, but nobody
cares. If you have a crash later on, that's always true - you don't get
crashes at nice well-defined points.

Linus


\
 
 \ /
  Last update: 2009-03-26 00:15    [W:0.695 / U:0.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site