[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <465F15ED.1070304@cfl.rr.com>
Date: Thu, 31 May 2007 14:37:33 -0400
From: Phillip Susi <psusi@....rr.com>
To: Jens Axboe <jens.axboe@...cle.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.
Jens Axboe wrote:
> 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.
I am saying that is the wrong thing to do. Barrier should be about
ordering only. So long as the order they hit the media is maintained,
the order the requests are completed in can change. barrier.txt bears
this out:
"Requests in ordered sequence are issued in order, but not required to
finish in order. Barrier implementation can handle out-of-order
completion of ordered sequence. IOW, the requests MUST be processed in
order but the hardware/software completion paths are allowed to reorder
completion notifications - eg. current SCSI midlayer doesn't preserve
completion order during error handling."
-
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