Re: Linux 2.6.29

From: Ric Wheeler
Date: Wed Mar 25 2009 - 20:32:51 EST


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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/