Messages in this thread | | | Date | Wed, 25 Mar 2009 20:28:58 -0400 | From | Ric Wheeler <> | Subject | Re: Linux 2.6.29 |
| |
Linus Torvalds wrote: > 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. > > In this case, you have not gained anything - same number of barrier operations/cache flushes and looser semantics for the transactions? > 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 > This is pretty much how write barriers work today - you carry down other transactions (even for other partitions on the same disk) with you...
ric
| |