[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4807377b0908311526r3b42f581j27b9c26166b7ac96@mail.gmail.com>
Date: Mon, 31 Aug 2009 15:26:42 -0700
From: Jesse Brandeburg <jesse.brandeburg@...il.com>
To: Jesse Brandeburg <jesse.brandeburg@...il.com>,
Theodore Tso <tytso@....edu>, Pavel Machek <pavel@....cz>,
NeilBrown <neilb@...e.de>, Ric Wheeler <rwheeler@...hat.com>,
Rob Landley <rob@...dley.net>, Florian Weimer <fweimer@....de>,
Goswin von Brederlow <goswin-v-b@....de>,
kernel list <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...l.org>, mtk.manpages@...il.com,
rdunlap@...otime.net, linux-doc@...r.kernel.org,
linux-ext4@...r.kernel.org, corbet@....net
Subject: Re: raid is dangerous but that's secret (was Re: [patch] ext2/3:
document conditions when reliable operation is possible)
On Mon, Aug 31, 2009 at 11:07 AM, martin f krafft<madduck@...ian.org> wrote:
> also sprach Jesse Brandeburg <jesse.brandeburg@...il.com> [2009.08.31.1949 +0200]:
>> In the case of a degraded array, could the kernel be more
>> proactive (or maybe even mdadm) and have the filesystem remount
>> itself withOUT journalling enabled? This seems on the surface to
>> be possible, but I don't know the internal particulars that might
>> prevent/allow it.
>
> Why would I want to disable the filesystem journal in that case?
I misspoke w.r.t journalling, the idea I was trying to get across was
to remount with -o sync while running on a degraded array, but given
some of the other comments in this thread I'm not even sure that would
help. the idea was to make writes as safe as possible (at the cost of
speed) when running on a degraded array, and to have the transition be
as hands-free as possible, just have the kernel (or mdadm) by default
remount.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists