linux-kernel - Re: [dm-devel] Barriers still not passing on simple dm devices...

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:	Wed, 8 Apr 2009 08:36:38 -0400 (EDT)
From:	Mikulas Patocka <mpatocka@...hat.com>
To:	Theodore Tso <tytso@....edu>
cc:	Ric Wheeler <rwheeler@...hat.com>,
	Jens Axboe <jens.axboe@...cle.com>,
	device-mapper development <dm-devel@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	ak@...ux.intel.com, "MASON, CHRISTOPHER" <CHRIS.MASON@...cle.com>
Subject: Re: [dm-devel] Barriers still not passing on simple dm devices...

> Even now, the reason why ext3 doesn't have barriers enabled by default
> (although we did make them the default for ext4) is because Andrew
> doesn't believe Chris's replication case is likely to be true for most
> users in practice, and he's concerned about the performance
> degradation of barriers.  He's basically depending on the fact that
> "usually" you can get away without using barriers.  Sigh....

What is the performance degradation of barriers?

If the disk doesn't have write cache, performance of barrier-filesystem 
should be equal or better than performance of the same filesystem not 
using barriers. If barriers degrade performance, there is something 
seriously broken, either in the filesystem (XFS...) or in the block layer.

If the disk has write cache and you disable barriers, you might get some 
performance improvement. But you are getting this performance improvement 
from the fact that the disk illegaly reorders writes that should be 
ordered. And you are going to damage your data on power failure.

--- definitely, very few admins want this "high-performance & damage" 
setup (maybe for /tmp or /var/log?) --- such condition sould be only 
enabled with admin fully knowning what's going on. And where should the 
admin get the knowledge?

In hdparm manpage, there is just:
-W     Get/set the IDE/SATA drive's write-caching feature.

> 						- Ted
> 
> P.S.  Of course, distributions should feel free to consider changing
> the default on their kernels.  SLES has already if memory serves
> correctly.  I don't know if RHEL has yet.

RHEL doesn't enable write cache by default. And doesn't use barriers (it 
uses lvm2/device mapper and they won't get through).

Mikulas
--
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/