[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0705311220080.17389@asgard.lang.hm>
Date: Thu, 31 May 2007 12:21:31 -0700 (PDT)
From: david@...g.hm
To: Jens Axboe <jens.axboe@...cle.com>
cc: Phillip Susi <psusi@....rr.com>, David Chinner <dgc@....com>,
Neil Brown <neilb@...e.de>, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, dm-devel@...hat.com,
linux-raid@...r.kernel.org, Stefan Bader <Stefan.Bader@...ibm.com>,
Andreas Dilger <adilger@...sterfs.com>,
Tejun Heo <htejun@...il.com>
Subject: Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems,
and dm/md.
On Thu, 31 May 2007, Jens Axboe wrote:
> On Thu, May 31 2007, Phillip Susi wrote:
>> David Chinner wrote:
>>> That sounds like a good idea - we can leave the existing
>>> WRITE_BARRIER behaviour unchanged and introduce a new WRITE_ORDERED
>>> behaviour that only guarantees ordering. The filesystem can then
>>> choose which to use where appropriate....
>>
>> So what if you want a synchronous write, but DON'T care about the order?
>> They need to be two completely different flags which you can choose
>> to combine, or use individually.
>
> If you have a use case for that, we can easily support it as well...
> Depending on the drive capabilities (FUA support or not), it may be
> nearly as slow as a "real" barrier write.
true, but a "real" barrier write could have significant side effects on
other writes that wouldn't happen with a synchronous wrote (a sync wrote
can have other, unrelated writes re-ordered around it, a barrier write
can't)
David Lang
-
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