On Sun, Oct 08 2017, John Stoffel wrote: >>>>>> "NeilBrown" == NeilBrown <neilb@xxxxxxxx> writes: > > NeilBrown> On Sun, Oct 08 2017, John Stoffel wrote: >>>>>>>> "NeilBrown" == NeilBrown <neilb@xxxxxxxx> writes: >>> > NeilBrown> On Wed, Oct 04 2017, John Stoffel wrote: >>>>> Since Eli had such a horrible experience where he shrunk the >>>>> individual component raid device size, instead of growing the overall >>>>> raid by adding a device, I came up with this hacky patch to warn you >>>>> when you are about to shoot yourself in the foot. >>>>> >>>>> The idea is it will warn you and exit unless you pass in the --force >>>>> (or -f) switch when using the command. For example, on a set of loop >>>>> devices: >>>>> >>>>> # cat /proc/mdstat >>>>> Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] >>>>> [raid4] [multipath] [faulty] >>>>> md99 : active raid6 loop4p1[4] loop3p1[3] loop2p1[2] loop1p1[1] >>>>> loop0p1[0] >>>>> 606720 blocks super 1.2 level 6, 512k chunk, algorithm 2 [5/5] >>>>> [UUUUU] >>>>> >>>>> # ./mdadm --grow /dev/md99 --size 128 >>>>> mdadm: Cannot set device size smaller than current component_size of /dev/md99 array. Use -f to force change. >>>>> >>>>> # ./mdadm --grow /dev/md99 --size 128 -f >>>>> mdadm: component size of /dev/md99 has been set to 0K >>>>> >>> > NeilBrown> I'm not sure I like this. > NeilBrown> The reason that mdadm will quietly accept a size change like this is > NeilBrown> that it is trivial to revert - just set the same to a big number and all > NeilBrown> your data is still there. >>> >>> This is wrong, because if you use --grow --size ### with a small >>> enough number, it destroys the MD raid superblock. > > NeilBrown> If that is true, then it is a kernel bug and should be fixed in the kernel. > > I just remembered another point I wanted to make. The earliest we get > such a change into the kernel is 4.15, and then maybe back ported into > some number of stable kernels. But by putting this check into mdadm > as well, we can protect people running older kernels as well. It > seems to me like a good arguement for fixing mdadm to: If there is some action that mdadm can currently be told to perform, and when it tries to perform that action it corrupts the array, then it is certainly appropriate to teach mdadm not to perform that action. It shouldn't even perform that action with --force. I agree that changing mdadm like this is complementary to changing the kernel. Both are useful. This is quite separate from any proposal to require --force to reduce the size with --grow --size. NeilBrown > > - adding the --grow --Force ... option. > - fixing the size check so you don't destroy the MD superblock even > with --Force. > - reporting to the user the pre- and post- size of array components > when using --grow --size ## > > Thanks, > John > -- > 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
Attachment:
signature.asc
Description: PGP signature
