Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757399AbZADPeS (ORCPT ); Sun, 4 Jan 2009 10:34:18 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751441AbZADPeI (ORCPT ); Sun, 4 Jan 2009 10:34:08 -0500 Received: from bombadil.infradead.org ([18.85.46.34]:36708 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750934AbZADPeI (ORCPT ); Sun, 4 Jan 2009 10:34:08 -0500 Date: Sun, 4 Jan 2009 10:34:01 -0500 From: Christoph Hellwig To: Alan Cox Cc: Christoph Hellwig , Adam Nielsen , LKML Mailinglist Subject: Re: XFS internal error xfs_da_do_buf(1) at line 2015 of file fs/xfs/xfs_da_btree.c Message-ID: <20090104153401.GA16185@infradead.org> References: <49600DE6.2080108@shikadi.net> <20090104074659.GA16775@infradead.org> <49607B5B.3070707@shikadi.net> <20090104092349.GA26194@infradead.org> <20090104114425.241f6630@lxorguk.ukuu.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090104114425.241f6630@lxorguk.ukuu.org.uk> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1332 Lines: 26 On Sun, Jan 04, 2009 at 11:44:25AM +0000, Alan Cox wrote: > Generally they avoid setting -W0 because it ruins performance and can be > very bad for disk lifetime. The barriers code is there for a reason. We've done measurements and for modern NCQ/TCQ disks the performance for cache off vs cache on + barriers is close. For ext3 barriers is generally slightly faster, and for XFS it's even or sometimes even cache off is faster depending on the workload. > Of course certain distributions default to using LVM for all their file > systems which is completely and mindbogglingly bogus. That both messes up > barriers in some cases and takes a good 10-20% off performance when I've > benched it. The thing is that there's no reason for that at all with just a single underlying disk. There is absolutely no reason for not passing through barriers, and there's also no reason why it should be any slower than our most trivially volume manager, the partition remapping code. In fact there's no reason trivial device mapper tables couldn't be handled by the partition remapping code.. -- 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/