linux-kernel - Re: [PATCH 2/7] ext3: call blkdev_issue

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: <49D28B1C.8030601@garzik.org>
Date:	Tue, 31 Mar 2009 17:29:00 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Jens Axboe <jens.axboe@...cle.com>
CC:	Tejun Heo <tj@...nel.org>, Theodore Tso <tytso@....edu>,
	Chris Mason <chris.mason@...cle.com>,
	Fernando Luis Vázquez Cao 
	<fernando@....ntt.co.jp>, Christoph Hellwig <hch@...radead.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	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>,
	david@...morbit.com
Subject: Re: [PATCH 2/7] ext3: call blkdev_issue_flush() on fsync()

Jens Axboe wrote:
> On Tue, Mar 31 2009, Tejun Heo wrote:
>> Hello,
>>
>> Theodore Tso wrote:
>>> On Mon, Mar 30, 2009 at 10:15:51AM -0400, Chris Mason wrote:
>>>> I'm not sure we want to stick Fernando with changing how barriers are
>>>> done in individual filesystems, his patch is just changing the existing
>>>> call points.
>>> Well, his patch actually added some calls to block_issue_flush().  But
>>> yes, it's probably better if he just changes the existing call points,
>>> and we can have the relevant filesystem maintainers double check to
>>> make sure that there aren't any new call points which are needed.
>> How about having something like blk_ensure_cache_flushed() which
>> issues flush iff there hasn't been any write since the last flush?
>> It'll be easy to implement and will filter out duplicate flushes in
>> most cases.
> 
> My original ide implementation of flushes actually did this. My memory
> is a little hazy on why it was dropped, I'm guessing because it
> basically never triggered anyway.

Yeah, and it probably wouldn't trigger today unless we add new code that 
starts generating enough duplicate cache flushes for this to be 
significant...

And since duplicate cache flushes are harmless to the drive, you're only 
talking about no-op ATA command overhead.  Which is only mildly notable 
on legacy IDE (eight or so inb/outb operations).

I would put duplicate cache flush filtering way, way down on the 
priority list, IMO.

	Jeff




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