|From:||Alan Cox <alan-AT-lxorguk.ukuu.org.uk>|
|To:||Linus Torvalds <torvalds-AT-linux-foundation.org>|
|Subject:||Re: [PATCH 1/7] block: Add block_flush_device()|
|Date:||Tue, 31 Mar 2009 17:29:11 +0100|
|Cc:||Ric Wheeler <rwheeler-AT-redhat.com>, Jens Axboe <jens.axboe-AT-oracle.com>, Fernando Luis =?ISO-8859-14?B?VuF6cXVleg==?= Cao <fernando-AT-oss.ntt.co.jp>, Jeff Garzik <jeff-AT-garzik.org>, Christoph Hellwig <hch-AT-infradead.org>, Theodore Tso <tytso-AT-mit.edu>, Ingo Molnar <mingo-AT-elte.hu>, Arjan van de Ven <arjan-AT-infradead.org>, Andrew Morton <akpm-AT-linux-foundation.org>, Peter Zijlstra <a.p.zijlstra-AT-chello.nl>, Nick Piggin <npiggin-AT-suse.de>, David Rees <drees76-AT-gmail.com>, Jesper Krogh <jesper-AT-krogh.cc>, Linux Kernel Mailing List <linux-kernel-AT-vger.kernel.org>, chris.mason-AT-oracle.com, david-AT-fromorbit.com, tj-AT-kernel.org|
> And the filesystem shouldn't know, and it most definitely mustr not act > any differently. Because that's behind the abstraction, and there's no > sane way to bring it _out_ of the abstraction that isn't fundamentally > flawed (like thinking that it's always a SATA-II drive). How the file system responds has to depend upon what the users intents are with regards to still having their data. In a lot of cases "flush if you can" makes good sense. In higher integrity cases you want a way to tell the device "flush if you can, do whatever else is needed to fake a flush if not" and in some cases you genuinely want to propogate errors back at mount time to say "sorry can't do this" Agreed entirely that this shouldn't be expressed down the stack in terms of things like 'tags' or 'write with fua', but unless the different versions of it can be expressed, or refused you can't build a good enough abstraction. Throw and pray the block layer can fake it simply isn't a valid model for serious enterprise computing, and if people understood the worst cases, for a lot of non enterprise computing. The second problem is who has sufficient information to efficiently handle decisions around ordering/barriers/flushes/single outstanding command and other strategies. I am skeptical that in the case where the underlying block subsystem provides suboptimal ordering/barrier facilities that it falling back to alternatives without letting the fs also change strategies will be efficient. Alan
Copyright © 2009, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds