[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 <tj kernel org>
- To: Vladislav Bolkhovitin <vst vlnb net>
- Cc: tytso mit edu, linux-scsi vger kernel org, jaxboe fusionio com, 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, jack suse cz, 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 15:21:36 +0200
Hello,
On 08/13/2010 02:55 PM, Vladislav Bolkhovitin wrote:
> If requested, I can develop the interface further.
I still think the benefit of ordering by tag would be marginal at
best, and what have you guys measured there? Under the current
framework, there's no easy way to measure full ordered-by-tag
implementation. The mechanism for filesystems to communicate the
ordering information (which would be a partially ordered graph) just
isn't there and there is no way the current usage of ordering-by-tag
only for barrier sequence can achieve anything close to that level of
difference.
Ripping out the original ordering by tag mechanism doesn't amount to
much. The use of ordering-by-tag was pretty half-assed there anyway.
If you think exporting full ordering information from filesystem to
the lower layers is worthwhile, please go ahead. It would be very
interesting to see how much actual difference it can make compared to
ordering-by-filesystem and if it's actually better and the added
complexity is manageable, there's no reason not to do that.
Thank you.
--
tejun
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]