On 18/10/17 15:48, John Stoffel wrote: >>>>>> "NeilBrown" == NeilBrown <neilb@xxxxxxxx> writes: > > NeilBrown> On Tue, Oct 17 2017, John Stoffel wrote: >>>>>>>> "NeilBrown" == NeilBrown <neilb@xxxxxxxx> writes: >>> > NeilBrown> Having both a bitmap and a journal is pointless. > NeilBrown> Attempting to do so can corrupt the bitmap if the journal > NeilBrown> replay happens before the bitmap is initialized. > NeilBrown> Rather than try to avoid this corruption, simply > NeilBrown> refuse to allow arrays with both a bitmap and a journal. > NeilBrown> So: > NeilBrown> - if raid5_run sees both are present, fail. >>> >>> So what happens if there's someone out there with an array setup with >>> both already? Should the journal or the bitmap be removed at this >>> time? > > NeilBrown> If someone has an array like that they can assemble it with > NeilBrown> --update=no-bitmap > > NeilBrown> I'd rather not automatically disable things. > > That works for me, assuming there's a useful message in the logs > explaining what's gone wrong here. Either mdadm emits the message, or > the kernel does. > Or are we better off, initially, just adding the code that prevents adding a bitmap or journal? Allow existing arrays to run, emitting messages to the console and/or log that this is not a good idea? Then maybe a few versions down the line actually refuse to start an array in this state. I don't know how many arrays are in this state now, but doing this should reduce the number of people getting a nasty shock when their system fails to boot ... Cheers, Wol -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
