[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070531062404.GH32105@kernel.dk>
Date: Thu, 31 May 2007 08:24:04 +0200
From: Jens Axboe <jens.axboe@...cle.com>
To: Phillip Susi <psusi@....rr.com>
Cc: device-mapper development <dm-devel@...hat.com>,
David Chinner <dgc@....com>, Tejun Heo <htejun@...il.com>,
linux-kernel@...r.kernel.org, linux-raid@...r.kernel.org,
linux-fsdevel@...r.kernel.org,
Andreas Dilger <adilger@...sterfs.com>,
Stefan Bader <Stefan.Bader@...ibm.com>
Subject: Re: [dm-devel] Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.
On Wed, May 30 2007, Phillip Susi wrote:
> >That would be the exactly how I understand Documentation/block/barrier.txt:
> >
> >"In other words, I/O barrier requests have the following two properties.
> >1. Request ordering
> >...
> >2. Forced flushing to physical medium"
> >
> >"So, I/O barriers need to guarantee that requests actually get written
> >to non-volatile medium in order."
>
> I think you misinterpret this, and it probably could be worded a bit
> better. The barrier request is about constraining the order. The
> forced flushing is one means to implement that constraint. The other
> alternative mentioned there is to use ordered tags. The key part there
> is "requests actually get written to non-volatile medium _in order_",
> not "before the request completes", which would be synchronous IO.
No Stephan is right, the barrier is both an ordering and integrity
constraint. If a driver completes a barrier request before that request
and previously submitted requests are on STABLE storage, then it
violates that principle. Look at the code and the various ordering
options.
--
Jens Axboe
-
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