[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [dm-devel] [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
- From: Christoph Hellwig <hch lst de>
- To: Tejun Heo <tj kernel org>
- Cc: tytso mit edu, linux-scsi vger kernel org, jaxboe fusionio com, jack suse cz, linux-kernel vger kernel org, swhiteho redhat com, linux-raid vger kernel org, linux-ide vger kernel org, dm-devel redhat com, James Bottomley suse de, konishi ryusuke lab ntt co jp, linux-fsdevel vger kernel org, vst vlnb net, rwheeler redhat com, hch lst de, chris mason oracle com
- Subject: Re: [dm-devel] [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
- Date: Fri, 13 Aug 2010 13:48:58 +0200
The patchset looks functionally correct to me, and with a small patch
to make use of WRITE_FUA_FLUSH survives xfstests, and instrumenting the
underlying qemu shows that we actually get the flush requests where we should.
No performance or power fail testing done yet.
But I do not like the transition very much. The new WRITE_FUA_FLUSH
request is exactly what filesystems expect from a current barrier
request, so I'd rather move to that functionality without breaking stuff
inbetween.
So if it was to me I'd keep patches 1, 2, 4 and 5 from your series, than
a main one to relax barrier semantics, then have the renaming patches 7
and 8, and possible keep patch 11 separate from the main implementation
change, and if absolutely also a separate one to introduce REQ_FUA and
REQ_FLUSH in the bio interface, but keep things working while doing
this.
Then we can patches do disable the reiserfs barrier "optimization" as
the very first one, and DM/MD support which I'm currently working on
as the last one and we can start doing the heavy testing.
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]