Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751972AbZIENlp (ORCPT ); Sat, 5 Sep 2009 09:41:45 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751894AbZIENlo (ORCPT ); Sat, 5 Sep 2009 09:41:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33811 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751775AbZIENln (ORCPT ); Sat, 5 Sep 2009 09:41:43 -0400 Message-ID: <4AA26A4D.5090309@redhat.com> Date: Sat, 05 Sep 2009 09:40:29 -0400 From: Ric Wheeler User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Lightning/1.0pre Thunderbird/3.0b3 MIME-Version: 1.0 To: Mark Lord CC: Krzysztof Halasa , Christoph Hellwig , Michael Tokarev , david@lang.hm, Pavel Machek , Theodore Tso , NeilBrown , Rob Landley , Florian Weimer , Goswin von Brederlow , kernel list , Andrew Morton , mtk.manpages@gmail.com, rdunlap@xenotime.net, linux-doc@vger.kernel.org, linux-ext4@vger.kernel.org, corbet@lwn.net Subject: Re: wishful thinking about atomic, multi-sector or full MD stripe width, writes in storage References: <20090828064449.GA27528@elf.ucw.cz> <20090828120854.GA8153@mit.edu> <20090830075135.GA1874@ucw.cz> <4A9A88B6.9050902@redhat.com> <4A9A9034.8000703@msgid.tls.msk.ru> <20090830163513.GA25899@infradead.org> <4A9BCCEF.7010402@redhat.com> <20090831131626.GA17325@infradead.org> <4A9BCDFE.50008@rtr.ca> <20090831132139.GA5425@infradead.org> <4A9F230F.40707@redhat.com> <4A9FA5F2.9090704@redhat.com> <4A9FC9B3.1080809@redhat.com> <4A9FCF6B.1080704@redhat.com> <4AA184D7.1010502@rtr.ca> <4AA186B0.5090905@redhat.com> <4AA26055.2090400@rtr.ca> In-Reply-To: <4AA26055.2090400@rtr.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1631 Lines: 42 On 09/05/2009 08:57 AM, Mark Lord wrote: > Ric Wheeler wrote: >> On 09/04/2009 05:21 PM, Mark Lord wrote: > .. >>> How about instead, *fixing* the MD layer to properly support barriers? >>> That would be far more useful, productive, and better for end-users. > .. >> Fixing MD would be great - not sure that it would end up still faster >> (look at md1 devices with working barriers with compared to md1 with >> write cache disabled). > .. > > There's no inherent reason for it to be slower, except possibly > drives with b0rked FUA support. > > So the first step is to fix MD to pass barriers to the LLDs > for most/all RAID types. > Then, if it has performance issues, those can be addressed > by more application of little grey cells. :) > > Cheers The performance issue with MD is that the "simple" answer is to not only pass on those downstream barrier ops, but also to block and wait until all of those dependent barrier ops complete before ack'ing the IO. When you do that implementation at least, you will see a very large performance impact and I am not sure that you would see any degradation vs just turning off the write caches. Sounds like we should actually do some testing and actually measure, I do think that it will vary with the class of device quite a lot just like we see with single disk barriers vs write cache disabled on SAS vs S-ATA, etc... ric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/