linux-kernel - Re: XFS internal error xfs_da_do_buf(1) at line 2015 of file fs/xfs/xfs_da

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 4 Jan 2009 10:34:01 -0500
From:	Christoph Hellwig <hch@...radead.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Adam Nielsen <a.nielsen@...kadi.net>,
	LKML Mailinglist <linux-kernel@...r.kernel.org>
Subject: Re: XFS internal error xfs_da_do_buf(1) at line 2015 of file
	fs/xfs/xfs_da_btree.c

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/