> [ ... ] 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. [ > ... ]
That does not make any sense, unless there is a fundamental mistake in the design of the 'raid1' profile, which this and other situations make me think is a possibility: that the category of "mirrored" 'raid1' chunk does not exist in the Btrfs chunk manager. That is, a chunk is either 'raid1' if it has a mirror, or if has no mirror it must be 'single'. If a member device of a 'raid1' profile multidevice volume disappears there will be "unmirrored" 'raid1' profile chunks and some code path must recognize them as such, but the logic of the code does not allow their creation. Question: how does the code know that a specific 'raid1' chunk is mirrored or not? The chunk must have a link (member, offset) to its mirror, do they? What makes me think that "unmirrored" 'raid1' profile chunks are "not a thing" is that it is impossible to remove explicitly a member device from a 'raid1' profile volume: first one has to 'convert' to 'single', and then the 'remove' copies back to the remaining devices the 'single' chunks that are on the explicitly 'remove'd device. Which to me seems absurd. Going further in my speculation, I suspect that at the core of the Btrfs multidevice design there is a persistent "confusion" (to use en euphemism) between volumes having a profile, and merely chunks have a profile. My additional guess that the original design concept had multidevice volumes to be merely containers for chunks of whichever mixed profiles, so a subvolume could have 'raid1' profile metadata and 'raid0' profile data, and another could have 'raid10' profile metadata and data, but since handling this turned out to be too hard, this was compromised into volumes having all metadata chunks to have the same profile and all data of the same profile, which requires special-case handling of corner cases, like volumes being converted or missing member devices. So in the case of 'raid1', a volume with say a 'raid1' data profile should have all-'raid1' and fully mirrored profile chunks, and the lack of a member devices fails that aim in two ways. -- 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
