[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 31 Mar 2009 10:26:58 +0900
From: Tejun Heo <tj@...nel.org>
To: Theodore Tso <tytso@....edu>, Chris Mason <chris.mason@...cle.com>,
Fernando Luis Vázquez Cao
<fernando@....ntt.co.jp>, Jeff Garzik <jeff@...zik.org>,
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, tj@...nel.org
Subject: Re: [PATCH 2/7] ext3: call blkdev_issue_flush() on fsync()
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.
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/
Powered by blists - more mailing lists