Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753807AbZIBWtu (ORCPT ); Wed, 2 Sep 2009 18:49:50 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753588AbZIBWtt (ORCPT ); Wed, 2 Sep 2009 18:49:49 -0400 Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]:38479 "EHLO grelber.thyrsus.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751266AbZIBWts (ORCPT ); Wed, 2 Sep 2009 18:49:48 -0400 From: Rob Landley Organization: Boundaries Unlimited To: Pavel Machek Subject: [PATCH] Update Documentation/md.txt to mention journaling won't help dirty+degraded case. Date: Wed, 2 Sep 2009 17:49:46 -0500 User-Agent: KMail/1.11.2 (Linux/2.6.28-14-generic; KDE/4.2.2; x86_64; ; ) Cc: Ric Wheeler , david@lang.hm, Theodore Tso , Florian Weimer , Goswin von Brederlow , kernel list , Andrew Morton , mtk.manpages@gmail.com, rdunlap@xenotime.net, linux-doc@vger.kernel.org, linux-ext4@vger.kernel.org, corbet@lwn.net References: <20090826001645.GN4300@elf.ucw.cz> <4A9910D5.4060208@redhat.com> <20090902201210.GC1840@ucw.cz> In-Reply-To: <20090902201210.GC1840@ucw.cz> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909021749.47695.rob@landley.net> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2063 Lines: 48 From: Rob Landley Add more warnings to the "Boot time assembly of degraded/dirty arrays" section, explaining that using a journaling filesystem can't overcome this problem. Signed-off-by: Rob Landley --- Documentation/md.txt | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/Documentation/md.txt b/Documentation/md.txt index 4edd39e..52b8450 100644 --- a/Documentation/md.txt +++ b/Documentation/md.txt @@ -75,6 +75,23 @@ So, to boot with a root filesystem of a dirty degraded raid[56], use md-mod.start_dirty_degraded=1 +Note that Journaling filesystems do not effectively protect data in this +case, because the update granularity of the RAID is larger than the journal +was designed to expect. Reconstructing data via partity information involes +matching together corresponding stripes, and updating only some of these +stripes renders the corresponding data in all the unmatched stripes +meaningless. Thus seemingly unrelated data in other parts of the filesystem +(stored in the unmatched stripes) can become unreadable after a partial +update, but the journal is only aware of the parts it modified, not the +"collateral damage" elsewhere in the filesystem which was affected by those +changes. + +Thus successful journal replay proves nothing in this context, and even a +full fsck only shows whether or not the filesystem's metadata was affected. +(A proper solution to this problem would involve adding journaling to the RAID +itself, at least during degraded writes. In the meantime, try not to allow +a system to shut down uncleanly with its RAID both dirty and degraded, it +can handle one but not both.) Superblock formats ------------------ -- Latency is more important than throughput. It's that simple. - Linus Torvalds -- 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/