[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
[dm-devel] Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.
- From: Neil Brown <neilb suse de>
- To: David Chinner <dgc sgi com>
- Cc: david lang hm, Tejun Heo <htejun gmail com>, linux-kernel vger kernel org, linux-raid vger kernel org, dm-devel redhat com, Jens Axboe <jens axboe oracle com>, linux-fsdevel vger kernel org, Andreas Dilger <adilger clusterfs com>
- Subject: [dm-devel] Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.
- Date: Fri, 1 Jun 2007 15:59:51 +1000
On Friday June 1, dgc sgi com wrote:
> On Thu, May 31, 2007 at 02:31:21PM -0400, 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?
>
> submit_bio(WRITE_SYNC, bio);
>
> Already there, already used by XFS, JFS and direct I/O.
Are you sure?
You seem to be saying that WRITE_SYNC causes the write to be safe on
media before the request returns. That isn't my understanding.
I think (from comments near the definition and a quick grep through
the code) that WRITE_SYNC expedites the delivery of the request
through the elevator, but doesn't do anything special about getting it
onto the media.
It essentially say "Submit this request now, don't wait for more
request to bundle with it for better bandwidth utilisation"
NeilBrown
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]