On 09/08/2022 15:50, David T-G wrote:
Hi, all --
I think that this has been asked before, and so I think that I know
where I'm
going, but before I take aim at my foot with a large-caliber mdadm ... :-)
I have an existing
diskfarm:~ # parted /dev/sda unit MiB print free
Model: ATA SanDisk SD6SB1M1 (scsi)
Disk /dev/sda: 122104MiB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: pmbr_boot
Number Start End Size File system Name Flags
0.02MiB 1.00MiB 0.98MiB Free Space
1 1.00MiB 33793MiB 33792MiB linux-swap(v1) diskfarm-swap
swap
2 33793MiB 66561MiB 32768MiB xfs diskfarmsuse
3 66561MiB 99329MiB 32768MiB diskfarmknop
legacy_boot
4 99329MiB 122104MiB 22775MiB xfs diskfarm-ssd
128G SSD. I have obtained a shiny new
diskfarm:~ # parted /dev/sde unit MiB print free
Model: ATA SATA SSD (scsi)
Disk /dev/sde: 244198MiB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
0.02MiB 1.00MiB 0.98MiB Free Space
1 1.00MiB 33793MiB 33792MiB diskfarm-swap swap
2 33793MiB 66561MiB 32768MiB diskfarmsuse
3 66561MiB 99329MiB 32768MiB diskfarmknop
legacy_boot
4 99329MiB 122104MiB 22775MiB diskfarm-ssd
122104MiB 244198MiB 122094MiB Free Space
256G SSD to use as a mirror. [You can ignore the sgdisk-copied partition
layout for the moment; that was a false start.] My final-view plan is, in
fact, to replace the 128 with another 256 and grow the -ssd data partition.
For a typical mirror-an-existing, I think that I need to create all of my
slices and the [degraded] mirror on the new, copy over the old, boot
from new,
and then treat old as just another disk to shove in. There's the
question of
making partitions larger for the RAID superblock info, though, and -- and
here's where I get confused -- even on the old disk when adding it in.
https://raid.wiki.kernel.org/index.php/Converting_an_existing_system
As you can see, I have no free space on the little guy. I was thinking I'd
bump my slices larger on the new disk so that I have room to spare to copy
everything over, with the data slice a little less larger than it would
have
been, but then ... I think I saw that I need to make the 2nd-drive slices
larger, too, so what do I do with the old guy?
Yup. If your old system is full (or even if it isn't), if you're moving
a straight partition on to raid, it's easier just to create all your
slices new on the new system and move across.
If you really want to re-use the old drive, then you've got some maths
ahead of you ...
You need to allocate the planned partition to your raid.
Then you create the raid, telling it to only use a space equal or less
than your original disk.
Then you copy your original filesystem into the raid, except it probably
doesn't quite fit, so you have to shrink it (not a simple matter) or use
cp or rsync instead, equally unpleasant.
Then you wipe your old drive and add it as the new raid member.
It's probably not hard. But it's got vastly more scope for error,
cock-up, fat-finger, or plain hardware hiccup. Is it worth it ...
And, in fact, does it even matter? If I understand this correctly, I'll be
running entirely from the new disk in the mirror once this is done, and
so it
doesn't matter whether I put the little old or the other big new in to
fill out
the mirror. If that's the case, then I don't really care about
partition size
because I'm going to start with mirrored partitions.
Yup again. You're better off just putting in a new 256GB.
Then you can just dd your old root (and whatever else) filesystem(s)
across, and grow them into the new space.
Plus your old drive is now just sitting there as a backup.
Oh, and just because I'm a glutton for punishment (even more than using
this
stupid webmail because we're currently down my home directory disk on
our mail
server and I'm impatient), if I'm essentially starting from scratch,
should I
mirror the entire [yes, identical] drive and partition the metadevice,
*BSD-style, or mirror individual partitions?
As my wife says about my driving, she trusts me, but there are too many
idiots out there. Advice is *ALWAYS* partition your hard drive. raid
couldn't care, but there are too many idiots out there that assume an
unpartitioned drive is empty, and will stomp on it without asking. It's
fallen off, but probably the biggest single cause of raid recoveries
here is "something overwrote my superblock with a partition table" or
the like - it's usually partition-related ...
Cheers,
Wol
