From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Daniel Phillips" Subject: Re: [Patch] document ext3 requirements (was Re: [RFD] Incremental fsck) Date: Tue, 15 Jan 2008 20:24:27 -0500 Message-ID: <4d47a5d10801151724m418e18efp9a0dd936e9a3584c@mail.gmail.com> References: <200801090022.55589.a1426z@gawab.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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Pavel Machek" , "David Chinner" , "Theodore Tso" , "Al Boldi" , "Valerie Henson" , "Rik van Riel" , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: "Alan Cox" Return-path: Received: from smtp-out.google.com ([216.239.45.13]:55448 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754759AbYAPBYh (ORCPT ); Tue, 15 Jan 2008 20:24:37 -0500 Received: from zps78.corp.google.com (zps78.corp.google.com [172.25.146.78]) by smtp-out.google.com with ESMTP id m0G1OT1M030282 for ; Tue, 15 Jan 2008 17:24:29 -0800 Received: from wa-out-1112.google.com (wafk22.prod.google.com [10.114.187.22]) by zps78.corp.google.com with ESMTP id m0G1NMNO030695 for ; Tue, 15 Jan 2008 17:24:28 -0800 Received: by wa-out-1112.google.com with SMTP id k22so114299waf.0 for ; Tue, 15 Jan 2008 17:24:28 -0800 (PST) In-Reply-To: <20080116001503.3c0c97cf@lxorguk.ukuu.org.uk> Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Jan 15, 2008 7:15 PM, 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. Indeed, you are right, which is supported by actual measurements: http://sr5tech.com/write_back_cache_experiments.htm Sorry for implying that anybody has engineered a drive that can do such a nice thing with writeback cache. The "disk motor as a generator" tale may not be purely folklore. When an IDE drive is not in writeback mode, something special needs to done to ensure the last write to media is not a scribble. A small UPS can make writeback mode actually reliable, provided the system is smart enough to take the drives out of writeback mode when the line power is off. Regards, Daniel