Hello helpful hands and chatters, On Fri, Jan 24, 2020 at 8:43 PM David T-G wrote:

% https://zedt.eu/tech/linux/migrating-existing-raid1-volumes-bigger-drives/ https://raid.wiki.kernel.org/index.php/Growing - add the larger drive(s) to the mirror

I am trying to make use of the yast partitioner module here as well and describing live what I observed. I added the first new larger physical disk to an available sata port on the machine. It became known e.g. as /dev/sde The yast partitioner module showed me the new disk /dev/sde and I there made it add a GPT based partition table (as the new large hdd was beyond 2TB of capacity). Then still inside the yast partitioner module I added an almost max size partition named /dev/sde1 and left it to not be formatted but selected linux raid file partition type, no file system selected no mount point no nothing. Then still inside yast partitioner module I navigated to the device tree and my raid logical settings inside yast partitioner module and there wanted to edit the raid and the constisting devices of the raid, but was always rejected when I tried to modify the participating devices/partitions. Yast2 partitioner module complained with a popup that the raid md127 was already established or finished and it could not be modified. Weird :( Yast2 paritioner module is not fit for such tasks? lizards.opensuse.org website speaks a lot about new development sprints and also often about yast2 and lot of module enhancements, and also about disk and partitioning module enhancements. Unfotunately the official leap 15.1 level modules dont seem to support raid1 methods to add this sde1 to already existing two e.g. sdb1 and sdc1 of that raid md127. Anyways, so I even removed the bitmap stuff according to those documentation and reports of others from the raid md127, e.g. from zedt.eu:

First off disable write intent bitmap (if enabled). mdadm --grow /dev/md127 --bitmap=none

And then went back into the yast paritioner module, but still no luck, would not let me add my third disk/parition to md127, so no /dev/sde1 here via yast paritioner.

- let the mirroring complete

So back to command line tools and adding the sde1:

mdadm --add /dev/md127 /dev/sde1

and growing command:

mdadm --grow --raid-devices=3 /dev/md127

(I added that --raid-devices number but wasnt sure if that was needed at all, was unclear according to manpage didnt say one absolutely must use that parameter? wonder what its really actually for in what circumstances it makes sense to use a number that maybe doesnt correspond to physical reality?) now /proc/mdstat shows its rebuilding and querying the md127 as well:

mdadm -QDv /dev/md127 /dev/md127: Version : 1.0 ---- ---- Raid Level : raid1 .... ... Raid Devices : 3 ... Total Devices : 3 State : clean, degraded, recovering ... Active Devices : 2 ... Working Devices : 3 ... Failed Devices : 0 ... Spare Devices : 1 ... Consistency Policy : resync ... Rebuild Status : 36% complete .... ... Number Major Minor RaidDevice State ... 0 8 17 0 active sync /dev/sdb1 ... 1 8 33 1 active sync /dev/sdc1 ... 2 8 65 2 spare rebuilding /dev/sde1

okay so far so good. Initially when I started venturing into this raid and growing and replacing with larger disks and all, I wouldnt feel at ease or at all couldnt think or cope with the idea that a mirror would consist of more than just two devices, so I couldnt come up with this basic step to first add another disk and so on. And spares and how all works into this. I am slowly now wrapping my head around it. Not by daily kind of stuff. Will wait for sync now. As I have limited sata ports available, I would probably need then to first fail/remove the sdb device after tht for example, so tht I free up a sata port first.

- remove the smaller drives

And I could only then remove the first old smaller physical disk e.g. sdb with its sdb1 partition. and then add probably second new larger physical sata disk, maybe becoming sdf? and continue from there? Will report back with the more steps I take and make and see if I succeed.

- grow the metadevice - grow the filesystem

YMMV and IANAL or even a Sys Admin any more, of course; use with caution and make backups first. Since you are running mirror, it would probably be an easy and VERY GOOD idea to break the mirror, put one drive aside, and remirror using only the original.

As stated above, whe I then later when sde completed rebuilding sde1, and I would need to remove sdb/sdb1 via the --fail and --remove command, would this freed up sdb device then still contain my data as an just in case backup? Or does a --fail and --remove kind of destroy the data structure or whatever details are on the disk, or can one still add this sdb device back later on? Then maybe only --fail parameter, and physically remove the sata disk, but not --remove command just yet? Then adding sdf and growing again and --fail sdc as well, and only at the very end --fail both old devices and as the final step --remove both old sdb and sdc devices? And then grow the actual filesystem on the md127 ? Thanks. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

To partly answer my own idea or question.... On Sat, Jan 25, 2020 at 5:15 PM cagsm wrote:

...

...

- let the mirroring complete So back to command line tools and adding the sde1: mdadm --add /dev/md127 /dev/sde1 and growing command: mdadm --grow --raid-devices=3 /dev/md127 (I added that --raid-devices number but wasnt sure if that was needed at all, was unclear according to manpage didnt say one absolutely must use that parameter? wonder what its really actually for in what circumstances it makes sense to use a number that maybe doesnt correspond to physical reality?) now /proc/mdstat shows its rebuilding and querying the md127 as well: okay the mirroring/growing of the outer raid devices to sde1 has completed successfully Now going into yast partitioner tool, in the "System View" tree, the RAID subtree, shows my raid, and in the used devices tab, even the opensuse partitioner tool now shows sdb1 sdc1 and sde1 as the

On Sat, Jan 25, 2020 at 3:52 PM cagsm wrote: participants. Wonder why I was unable or disallowed to add the sde1 inside the gui paritioner module. Lack of features? :( What would be by next step now? Really remove (--fail) the sdb1 component of this raid1? Maybe trying this from inside the yast partitioner tool now? Will report back.

Inside the yast partitioner module, when in that System View -> RAID tree -> raid name -> Used Devices -> Change... that "Change..." Button pressed, also again only gives the error popup dialoge:

The RAID /dev/md/raidname..... is already created on disks and its used devices cannot be modified. To modify the used devices, remove the RAID and create it again.

End of dialoge. Odd. So yast paritioner module has no or too little functionality regarding this aspect of the situation and raid and devices handling. Or am I doing it wrong? ;( Anyways, will then now probably continue with command line tools as given on the zedt.eu website stating:

Then soft-fail and remove the old disk from the arrays:

Any further hints to my question if I should only first use the --fail command and physically detach the failed (sdb1) device from the machine, freeing up the sata port on the machine, so I can add the second larger disk for the raid1 mirror? TY. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 25/01/2020 17.27, cagsm wrote: | Any further hints to my question if I should only first use the | --fail command and physically detach the failed (sdb1) device from | the machine, freeing up the sata port on the machine, so I can add | the second larger disk for the raid1 mirror? I think you should detach the failed disk another day - or somewhat later, after verifying a second time that all is Ok. The "failed" disk should contain a workable copy of all. You could put it on another machine and recreate a working mirror again. It can be a method for backup. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXi16SQAKCRC1MxgcbY1H 1V0BAJ0YihEqdwwg3npJuw67Oru4jY8YygCfev+xpBDcSHvSvMx+JeTit4EL1ww= =p3DI -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sun, Jan 26, 2020 at 3:11 PM cagsm wrote:

Now I will try to actually fail the now shuffled around old sdb smaller physical disk, or maybe the other small sdc physical disk and then add the second larger physical disk. I will then need to clone the GPT and partition table information stuff from the first larger physical disk I guess to make them actually kind of identical in partition layout.

Progressing here now: As my smaller sata drives had previously been inside a sata enclosure, I wanted to move the newer larger drives as quickly as possible into that sata enclosure. So thats why as well shuffled around the first old smaller drive, thus bringing it to the outside. The first new larger sata drive is now inside the sata enclosure, together with the second older smaller sata drive. So now it was time to fail that second smaller still enclosure encased sata drive, first identifying it by its real serial number, or better say looking up the serial number of the still hidden second smaller sata drive inside the sata enclosure via:

smartctl --all /dev/sdb1 | more

then making sure that serial number displayed there was not the serial number of the now-outside smaller sata first drive. then failing and remove and then physically disconnecting it from inside the sata enclosure, turning off power of that sata enclosure slot and ejecting it.

mdadm --fail /dev/md127 /dev/sdb1 mdadm --remove /dev/md127 /dev/sdb1

Now attaching the new second larger sata disk physically into the freed sata enclosure slot. Giving me again a now newly populated physical sata device named sdb again. Now with the help of sgdisk tool, for gpt disk handling, backing up the gpt and partitioning table information from my first larger sata hdd disk added previousl, first saving table information into a file named "table"

sgdisk --backup=table /dev/sdc

Then writing this information from sdc to tne new larger physical disk now named sdb:

sgdisk --load-backup=table /dev/sdb

And finally randomizing this cloned information and its UUID stuff for real world use with sgdisk again:

-G, --randomize-guids Randomize the disk's GUID and all partitions' unique GUIDs (but not their partition type code GUIDs). This function may be used after cloning a disk in order to render all GUIDs once again unique.

sgdisk -G /dev/sdb

This giving it a proper near identical cloned sdb1 partition layout, cloned from sdc (sdc1). Then I turned off the bitmap again:

mdadm --grow /dev/md127 --bitmap=none

and adding the second large sata hdd, named sdb1 to the md127 raid1 device:

mdadm --add /dev/md127 /dev/sdb1

And then growing the outer md raid device to make use of all the three disks for its raid1:

mdadm --grow --raid-devices=3 /dev/md127

Now waiting for a proper sync/rebuild, showing via e.g.

mdadm -QDv /dev/md127 State : clean, degraded, recovering Rebuild Status : 19% complete ... 1 8 49 0 active sync /dev/sdd1 2 8 33 1 active sync /dev/sdc1 3 8 17 2 spare rebuilding /dev/sdb1

.... waiting for completion to then continue with removing the leftover first small hdd and be done with physical stuff, then still needing to regrow the md127 device to larger capacity of the newer larger hdd disks used for it, and later regrowing the filesystem as well to make use of the additonal space as well. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org