02.03.2017 16:41, Duncan пишет: > Chris Murphy posted on Wed, 01 Mar 2017 17:30:37 -0700 as excerpted: > >> [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. >> 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. > > AFAIK, no, it hasn't been fixed, at least not in mainline, because the > patches to fix it got stuck in some long-running project patch queue > (IIRC, the one for on-degraded auto-device-replace), with no timeline > known to me on mainline merge. > > Meanwhile, the problem as I understand it is that at the first raid1 > degraded writable mount, no single-mode chunks exist, but without the > second device, they are created.
Is not it the root cause? I would expect it to create degraded mirrored chunks that will be synchronized when second device is added back. (It's not clear to me whether they are > created with the first write, that is, ignoring any space in existing > degraded raid1 chunks, or if that's used up first and the single-mode > chunks only created later, when a new chunk must be allocated to continue > writing as the old ones are full.) > > So the first degraded-writable mount is allowed, because no single-mode > chunks yet exist, while after such single-mode chunks are created, the > existing dumb algorithm won't allow further writable mounts, because it > sees single-mode chunks on a multi-device filesystem, and never mind that > all the single mode chunks are there, it simply doesn't check that and > won't allow writable mount because some /might/ be on the missing device. > > The patches stuck in queue would make btrfs more intelligent about that, > having it check each chunk as listed in the chunk tree, and if at least > one copy is available (as would be the case for single-mode chunks > created after the degraded mount), writable mount would still be > allowed. But... that's stuck in a long running project queue with no > known timetable for merging... <grumble, grumble>... so the only way to > get it is to go find and merge them yourself, in your own build. > Will it replicate single mode chunks when second device is added? -- 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
