Am Mittwoch, 30. November 2016, 10:38:08 CET schrieb Roman Mamedov:
> On Wed, 30 Nov 2016 00:16:48 +0100
> Wilson Meier <wilson.me...@gmail.com> wrote:
> > That said, btrfs shouldn't be used for other then raid1 as every other
> > raid level has serious problems or at least doesn't work as the expected
> > raid level (in terms of failure recovery).
> RAID1 shouldn't be used either:
> *) Read performance is not optimized: all metadata is always read from the
> first device unless it has failed, data reads are supposedly balanced
> between devices per PID of the process reading. Better implementations
> dispatch reads per request to devices that are currently idle.
> *) Write performance is not optimized, during long full bandwidth sequential
> writes it is common to see devices writing not in parallel, but with a long
> periods of just one device writing, then another. (Admittedly have been
> some time since I tested that).
> *) A degraded RAID1 won't mount by default.
> If this was the root filesystem, the machine won't boot.
> To mount it, you need to add the "degraded" mount option.
> However you have exactly a single chance at that, you MUST restore the RAID
> to non-degraded state while it's mounted during that session, since it
> won't ever mount again in the r/w+degraded mode, and in r/o mode you can't
> perform any operations on the filesystem, including adding/removing
> *) It does not properly handle a device disappearing during operation.
> (There is a patchset to add that).
> *) It does not properly handle said device returning (under a
> different /dev/sdX name, for bonus points).
> Most of these also apply to all other RAID levels.
So the stability matrix would need to be updated not to recommend any kind of
BTRFS RAID 1 at the moment?
Actually I faced the BTRFS RAID 1 read only after first attempt of mounting it
"degraded" just a short time ago.
BTRFS still needs way more stability work it seems to me.
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html