On Thu, Oct 31, 2019 at 11:17 AM David Sterba <dsterba@xxxxxxxx> wrote: > > Here it goes again, RAID1 with 3- and 4- copies. I found the bug that stopped > it from inclusion last time, it was in the test itself, so the kernel code is > effectively unchanged. > > So, with 1 or 2 missing devices, replace by device id works. There's one > annoying thing but not new: regarding replace of a missing device, some > extra single/dup block groups are created during the replace process. > Example below. This can happen on plain raid1 with degraded read-write > mount as well. > > Now what's the merge target. > > The patches almost made it to 5.3, the changes build on existing code so the > actual addition of new profiles is namely in the definitions and additional > cases. So it should be safe. > > I'm for adding it to 5.5 queue, though we're at rc5 and this can be seen as a > late time for a feature. The user benefits are noticeable, raid1c3 can replace > raid6 of metadata which is the most problematic part and much more complicated > to fix (write ahead journal or something like that). The feedback regarding the > plain 3-copy as a replacement was positive, on IRC and there are mails about > that too. > What's the reasoning for not submitting this for 5.4? I think the improvements here are definitely worth pulling into the 5.4 kernel release... -- 真実はいつも一つ！/ Always, there's only one truth!
