linux-kernel - Re: [PATCH 1/7] block: Add block_flush

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.0903310846110.4093@localhost.localdomain>
Date:	Tue, 31 Mar 2009 08:54:23 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ric Wheeler <rwheeler@...hat.com>
cc:	Jens Axboe <jens.axboe@...cle.com>,
	Fernando Luis Vázquez Cao 
	<fernando@....ntt.co.jp>, Jeff Garzik <jeff@...zik.org>,
	Christoph Hellwig <hch@...radead.org>,
	Theodore Tso <tytso@....edu>, Ingo Molnar <mingo@...e.hu>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Arjan van de Ven <arjan@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Nick Piggin <npiggin@...e.de>, David Rees <drees76@...il.com>,
	Jesper Krogh <jesper@...gh.cc>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	chris.mason@...cle.com, david@...morbit.com, tj@...nel.org
Subject: Re: [PATCH 1/7] block: Add block_flush_device()

On Tue, 31 Mar 2009, Linus Torvalds wrote:
> 
> Ok? Until you can see the bigger picture, just don't bother.

And this is really what it boils down to. Abstraction. Bigger picture. And 
the fact that the filesystem should DAMN WELL NOT THINK IT KNOWS WHAT IS 
GOING ON!

This is also fundamentally why returning that particular error is 
pointless. If the driver returns EOPNOTSUPP, there is simply never _any_ 
possible reason for upper layers to ever be informed about it - because 
there is not _any_ possible situation where they can do anything about it. 

Even _thinking_ that they can do something about it is fundamentally 
flawed. It misses the entire point of having layering and abstraction and 
having a "block layer" there to do these kinds of things.

If you want to write your filesystem so that it interacts with the 
low-level device directly, go and write an MTD filesystem instead. Don't 
even _claim_ to care about generic filesystems like 'ext3' or something 
like that. 

But if you try to be a "real" filesystem (ie general-purpose, meant to 
work on any random block device), don't come and whine about it when the 
block device then doesn't really do anything but read or write, or when 
the driver literally doesn't even _know_ how to serialize something 
because it doesn't even make sense in its world-view.

Don't mix up block layer and low-level driver issues with filesystem 
issues. The filesystem should say "block layer: flush the pending writes". 
And the block layer should try its best, but if the low-level driver says 
"that operation doesn't make sense for me", the block layer should just 
say "ok, whatever".

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).

		Linus
--
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/