Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753609AbYAPV3A (ORCPT ); Wed, 16 Jan 2008 16:29:00 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751194AbYAPV2v (ORCPT ); Wed, 16 Jan 2008 16:28:51 -0500 Received: from mx1.redhat.com ([66.187.233.31]:45588 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750917AbYAPV2t (ORCPT ); Wed, 16 Jan 2008 16:28:49 -0500 Message-ID: <478E76F4.3090605@sandeen.net> Date: Wed, 16 Jan 2008 15:28:20 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Alan Cox CC: Daniel Phillips , Pavel Machek , David Chinner , Theodore Tso , Al Boldi , Valerie Henson , Rik van Riel , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [Patch] document ext3 requirements (was Re: [RFD] Incremental fsck) References: <200801090022.55589.a1426z@gawab.com> <200801090740.12989.a1426z@gawab.com> <70b6f0bf0801082345vf57951ey642e35c3d6e5194f@mail.gmail.com> <200801091452.14890.a1426z@gawab.com> <20080112145140.GB6751@mit.edu> <20080113171916.GB4132@ucw.cz> <20080113174125.5f39ac64@lxorguk.ukuu.org.uk> <20080115201653.GA5639@elf.ucw.cz> <20080115214325.GN155407@sgi.com> <20080115230714.GC3573@elf.ucw.cz> <4d47a5d10801151544k3bc50223ob69c25d8732e3f12@mail.gmail.com> <20080116001503.3c0c97cf@lxorguk.ukuu.org.uk> In-Reply-To: <20080116001503.3c0c97cf@lxorguk.ukuu.org.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1064 Lines: 25 Alan Cox wrote: >> Writeback cache on disk in iteself is not bad, it only gets bad if the >> disk is not engineered to save all its dirty cache on power loss, >> using the disk motor as a generator or alternatively a small battery. >> It would be awfully nice to know which brands fail here, if any, >> because writeback cache is a big performance booster. > > AFAIK no drive saves the cache. The worst case cache flush for drives is > several seconds with no retries and a couple of minutes if something > really bad happens. > > This is why the kernel has some knowledge of barriers and uses them to > issue flushes when needed. Problem is, ext3 has barriers off by default so it's not saving most people. And then if you turn them on, but have your filesystem on an lvm device, lvm strips them out again. -Eric -- 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/