On 2017-03-03 00:56, Kai Krakow wrote:
Am Thu, 2 Mar 2017 11:37:53 +0100
schrieb Adam Borowski <kilob...@angband.pl>:
On Wed, Mar 01, 2017 at 05:30:37PM -0700, Chris Murphy wrote:
[1717713.408675] BTRFS warning (device dm-8): missing devices (1)
exceeds the limit (0), writeable mount is not allowed
[1717713.446453] BTRFS error (device dm-8): open_ctree failed
[chris@f25s ~]$ uname -r
4.9.8-200.fc25.x86_64
I thought this was fixed. I'm still getting a one time degraded rw
mount, after that it's no longer allowed, which really doesn't make
any sense because those single chunks are on the drive I'm trying to
mount.
Well, there's Qu's patch at:
https://www.spinics.net/lists/linux-btrfs/msg47283.html
but it doesn't apply cleanly nor is easy to rebase to current kernels.
I don't understand what problem this proscription is trying to
avoid. If it's OK to mount rw,degraded once, then it's OK to allow
it twice. If it's not OK twice, it's not OK once.
Well, yeah. The current check is naive and wrong. It does have a
purpose, just fails in this, very common, case.
I guess the reasoning behind this is: Creating any more chunks on this
drive will make raid1 chunks with only one copy. Adding another drive
later will not replay the copies without user interaction. Is that true?
If yes, this may leave you with a mixed case of having a raid1 drive
with some chunks not mirrored and some mirrored. When the other drives
goes missing later, you are loosing data or even the whole filesystem
although you were left with the (wrong) imagination of having a
mirrored drive setup...
Is this how it works?
If yes, a real patch would also need to replay the missing copies after
adding a new drive.
The problem is that that would use some serious disk bandwidth without
user intervention. The way from userspace to fix this is to scrub the
FS. It would essentially be the same from kernel space, which means
that if you had a multi-TB FS and this happened, you'd be running at
below capacity in terms of bandwidth for quite some time. If this were
to be implemented, it would have to be keyed off of the per-chunk
degraded check (so that _only_ the chunks that need it get touched), and
there would need to be a switch to disable it.
--
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
