Re: raid is dangerous but that's secret (was Re: [patch] ext2/3: document conditions when reliable operation is possible)
From: Jesse Brandeburg <hidden>
Date: 2009-08-31 22:26:42
Also in:
lkml
Possibly related (same subject, not in this thread)
- 2009-11-09 · Re: raid is dangerous but that's secret (was Re: [patch] ext2/3: document conditions when reliable operation is possible) · Pavel Machek <hidden>
- 2009-09-05 · Re: raid is dangerous but that's secret (was Re: [patch] ext2/3: document conditions when reliable operation is possible) · Pavel Machek <hidden>
- 2009-09-03 · Re: raid is dangerous but that's secret (was Re: [patch] ext2/3: document conditions when reliable operation is possible) · <hidden>
- 2009-09-03 · Re: raid is dangerous but that's secret (was Re: [patch] ext2/3: document conditions when reliable operation is possible) · Krzysztof Halasa <khc@pm.waw.pl>
- 2009-09-03 · Re: raid is dangerous but that's secret (was Re: [patch] ext2/3: document conditions when reliable operation is possible) · Ric Wheeler <hidden>
On Mon, Aug 31, 2009 at 11:07 AM, martin f krafft[off-list ref] wrote:
also sprach Jesse Brandeburg [off-list ref] [2009.08.31.1949 +0200]:quoted
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html