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: Thu, 17 Jan 2008 17:51:56 -0500 Message-ID: <4d47a5d10801171451n50c91097m12a22a49e3c04884@mail.gmail.com> 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> <4d47a5d10801151744t378ecdcbj1c326181b4360452@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Pavel Machek" , "Alan Cox" , "Theodore Tso" , "Al Boldi" , "Valerie Henson" , "Rik van Riel" , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: "Szabolcs Szakacsits" Return-path: Received: from smtp-out.google.com ([216.239.33.17]:5658 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1761124AbYAQWwS (ORCPT ); Thu, 17 Jan 2008 17:52:18 -0500 Received: from zps77.corp.google.com (zps77.corp.google.com [172.25.146.77]) by smtp-out.google.com with ESMTP id m0HMpwSo008500 for ; Thu, 17 Jan 2008 22:51:58 GMT Received: from wa-out-1112.google.com (wahj5.prod.google.com [10.114.236.5]) by zps77.corp.google.com with ESMTP id m0HMp0rJ030656 for ; Thu, 17 Jan 2008 14:51:56 -0800 Received: by wa-out-1112.google.com with SMTP id j5so1336034wah.24 for ; Thu, 17 Jan 2008 14:51:56 -0800 (PST) In-Reply-To: Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Jan 17, 2008 7:29 AM, Szabolcs Szakacsits wrote: > Similarly to ZFS, Windows Server 2008 also has self-healing NTFS: I guess that is enough votes to justify going ahead and trying an implementation of the reverse mapping ideas I posted. But of course more votes for this is better. If online incremental fsck is something people want, then please speak up here and that will very definitely help make it happen. On the walk-before-run principle, it would initially just be filesystem checking, not repair. But even this would help, by setting per-group checked flags that offline fsck could use to do a much quicker repair pass. And it will let you know when a volume needs to be taken offline without having to build in planned downtime just in case, which already eats a bunch of nines. Regards, Daniel