Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1764727AbZDHMh3 (ORCPT ); Wed, 8 Apr 2009 08:37:29 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755205AbZDHMhH (ORCPT ); Wed, 8 Apr 2009 08:37:07 -0400 Received: from mx1.redhat.com ([66.187.233.31]:54693 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754615AbZDHMhF (ORCPT ); Wed, 8 Apr 2009 08:37:05 -0400 Date: Wed, 8 Apr 2009 08:36:38 -0400 (EDT) From: Mikulas Patocka X-X-Sender: mpatocka@hs20-bc2-1.build.redhat.com To: Theodore Tso cc: Ric Wheeler , Jens Axboe , device-mapper development , Linux Kernel Mailing List , ak@linux.intel.com, "MASON, CHRISTOPHER" Subject: Re: [dm-devel] Barriers still not passing on simple dm devices... In-Reply-To: <20090405012839.GF7553@mit.edu> Message-ID: References: <20090324150517.GX27476@kernel.dk> <20090325152751.GV27476@kernel.dk> <20090326084205.GG27476@kernel.dk> <20090331104933.GJ5178@kernel.dk> <20090403081131.GP5178@kernel.dk> <49D77AC3.3020207@redhat.com> <20090405012839.GF7553@mit.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1949 Lines: 42 > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/