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: <49D2BB63.3080706@kernel.org>
Date:	Wed, 01 Apr 2009 09:54:59 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Jens Axboe <jens.axboe@...cle.com>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ric Wheeler <rwheeler@...hat.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
Subject: Re: [PATCH 1/7] block: Add block_flush_device()

Hello,

Jens Axboe wrote:
>> For example, if the drive doesn't support FUA, then you cannot do a 
>> serialized IO operation, but you can still mostly do a serialized op 
>> without any IO attached to it.
> 
> FUA we should be able to reliably detect, it's really the cache flush
> operation itself that has caused headaches in the past. The -EOPNOTSUPP
> really comes from the block layer, not from the device driver. That's
> mainly due to the fact that we only send down the actual barrier, if the
> driver already said it supported them. If they do fail them, we probably
> need to pick up the -EIO bits and pieces and pretend it didn't happen as
> well. So it definitely needs more looking into, auditing, and testing.
> I'll do that tomorrow.

Yeah, we need to implement some kind of fallback logic such that
filesystems get errors iff the underlying device actually failed to
flush.  For the most part, this shouldn't be too difficult.

There is a corner case for tag ordered requests in that retrying
might end up putting the barrier on the platter after writes following
it.  Well, the problem isn't specific to fallback tho.  The root
problem is that later command get issued before the previous ones are
finished and SCSI ordered tag doesn't mandate failure of earlier
request to abort all the following ones, so by the time block layer
knows about the failure, writes after the barrier might already be on
the platter.  I guess we'll have to ignore that for the time being.

Thanks.

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