mirroring existing boot drive sanity check

mirroring existing boot drive sanity check

[David T-G]

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.

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?

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.

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?


Thanks as always!

:-D
-- 
David T-G
See http://justpickone.org/davidtg/email/
See http://justpickone.org/davidtg/tofu.txt

Re: mirroring existing boot drive sanity check

[Wols Lists]

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

Re: mirroring existing boot drive sanity check

[Pascal Hambourg]

Le 09/08/2022 à 16:50, David T-G a écrit :
> 
> I have an existing 128G SSD.
> 
>    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
> 
> I have obtained a shiny new 256G SSD to use as a mirror.
> 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
If you choose to copy existing block device content (with dd or the 
like) into a RAID array, then the RAID array device size must be at 
least the same this, which implies that the RAID member devices is 
sligthly bigger to take the RAID superblock into account.

If you choose to copy filesystem content (with cp, rsync or the like) 
into a new filesystem, then you only need the RAID array device to be 
big enough to fit the content.

> As you can see, I have no free space on the little guy.

Actually no, we cannot see. We can only see that there is no free space 
outside the partitions. But we cannot see if there is any free space 
inside the partitions.

> what do I do with the old guy?

Do whatever you like with the old drive except using it in the RAID 
array. Why bother doing this and having to resize the RAID array when 
you add the 2nd new drive ? Resizing a RAID array is a pain in the ass. 
Just build the RAID array on the 2 new drives from the start.

> 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?

IMO a single RAID array is simpler. If your distribution supports it, 
you can either partition it with a partition table or use it as a LVM 
physical volume and create logical volumes.

However I do not think it is possible to cleanly boot from an 
unpartitioned drive used as a software RAID member, as a RAID capable 
boot loader could hardly fit in the 4-KiB area before the RAID 
superblock. So you still have to create a partition table on the raw 
drives. Also, if you use GPT format and GRUB boot loader, you need to 
create a small (100 kB to 1 MB) partition with type "BIOS boot" (or 
libparted bios_grub flag).

Re: mirroring existing boot drive sanity check

[Wols Lists]

On 11/08/2022 22:26, Pascal Hambourg wrote:
> However I do not think it is possible to cleanly boot from an 
> unpartitioned drive used as a software RAID member, as a RAID capable 
> boot loader could hardly fit in the 4-KiB area before the RAID 
> superblock. So you still have to create a partition table on the raw 
> drives. Also, if you use GPT format and GRUB boot loader, you need to 
> create a small (100 kB to 1 MB) partition with type "BIOS boot" (or 
> libparted bios_grub flag).

Firstly, is there a 4K block there? iirc it's only 1.2 that leaves said 
block.

And secondly, does raid assume that 4K space belongs to it? I know it's 
seen as a safety space, so there's nothing permanent left there, but 
that's no guarantee raid doesn't think "that's mine, I'll stash 
something there temporarily". After all, the space allocated explicitly 
begins at the start of the 4K.

(That's completely different to the rouge tools the space is there to 
protect - those tools that think "that's nobody's, I'll just grab it".)

Cheers,
Wol

Re: mirroring existing boot drive sanity check

[Pascal Hambourg]

Le 12/08/2022 à 09:23, Wols Lists a écrit :
> On 11/08/2022 22:26, Pascal Hambourg wrote:
>> However I do not think it is possible to cleanly boot from an 
>> unpartitioned drive used as a software RAID member, as a RAID capable 
>> boot loader could hardly fit in the 4-KiB area before the RAID 
>> superblock.
> 
> Firstly, is there a 4K block there? iirc it's only 1.2 that leaves said 
> block.

Yes, but 1.2 is the default, so I assumed it.

> And secondly, does raid assume that 4K space belongs to it? I know it's 
> seen as a safety space, so there's nothing permanent left there, but 
> that's no guarantee raid doesn't think "that's mine, I'll stash 
> something there temporarily". After all, the space allocated explicitly 
> begins at the start of the 4K.

On one hand other 1.x subversions do not have that 4-KiB space so I 
assume it is not used. Also the gap between the superblock and the data 
may be used to hold temporary stuff.

On the other hand ext* filesystems do not use the first sector either 
but mke2fs erases it anyway, wiping any existing boot sector.

Anyway, as I wrote previously, no usable boot loader would fit there, so 
the point is moot.