public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Christoph Hellwig <hch@infradead.org>,
	Adam Nielsen <a.nielsen@shikadi.net>,
	LKML Mailinglist <linux-kernel@vger.kernel.org>
Subject: Re: XFS internal error xfs_da_do_buf(1) at line 2015 of file fs/xfs/xfs_da_btree.c
Date: Sun, 4 Jan 2009 10:34:01 -0500	[thread overview]
Message-ID: <20090104153401.GA16185@infradead.org> (raw)
In-Reply-To: <20090104114425.241f6630@lxorguk.ukuu.org.uk>

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..


  reply	other threads:[~2009-01-04 15:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-04  1:16 XFS internal error xfs_da_do_buf(1) at line 2015 of file fs/xfs/xfs_da_btree.c Adam Nielsen
2009-01-04  7:46 ` Christoph Hellwig
2009-01-04  9:03   ` Adam Nielsen
2009-01-04  9:23     ` Christoph Hellwig
2009-01-04 11:44       ` Alan Cox
2009-01-04 15:34         ` Christoph Hellwig [this message]
2009-01-04 15:50           ` Andi Kleen
2009-01-05  5:12         ` markus reichelt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090104153401.GA16185@infradead.org \
    --to=hch@infradead.org \
    --cc=a.nielsen@shikadi.net \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox