[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: Tejun Heo <teheo suse de>
- To: Christoph Hellwig <hch lst de>
- Cc: tytso mit edu, linux-scsi vger kernel org, jaxboe fusionio com, jack suse cz, linux-kernel vger kernel org, 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, swhiteho redhat com, chris mason oracle com
- Subject: Re: [dm-devel] [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
- Date: Wed, 18 Aug 2010 10:11:22 +0200
Hello,
On 08/18/2010 08:35 AM, Tejun Heo wrote:
>> It's not bisecting to find bugs in the barrier conversion. We can't
>> easily bisect it down anyway. The problem is when we try to bisect
>> other problems and get into the middle of the series barriers suddenly
>> are gone. Which is not very helpful for things like data integrity
>> problems in filesystems.
>
> Ah, okay, hmmm.... alright, I'll resequence the patches. If the
> filesystem changes can be put into a single tree somehow, we can keep
> things mostly working at least for direct devices.
Sorry but I'm doing it. It just doesn't make much sense. I can't
relax the ordering for REQ_HARDBARRIER without breaking the remapping
drivers. So, to keep things working, I'll have to 1. relax the
ordering 2. implement new REQ_FLUSH/FUA based interface and 3. use
them in the filesystems in the same patch. That's just wrong. And I
don't think md/dm changes can or should go through the block tree.
They're way too invasive for that. It's a new implementation and
barrier won't work (fail gracefully) for several commits during the
transition. I don't think there's a better way around it.
Thanks.
--
tejun
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]