Ssd, mdadm & raid1

ferg · Posted: Sat Oct 10, 2020 8:38 am Post subject: Ssd, mdadm & raid1

I've just moved my root partition on a RAID1 device from spinning disks to two new fancy SSDs.

I did this by:

Failing one disk and removing it.
Replacing it with an SSD
Syncing
Repeating with the other disk
Finally growing the RAID1 device and resizing the filesystem

So I did not recreate the raid1 device.

However, now I've come to read the Gentoo SSD wiki I realise that there are quite a few things I should have done.

Mainly:

I should have aligned the partitions when I created them. I used Fdisk so I guess this is not done automatically
I should have have reformatted the EXT4 partition to match the ERASE block size of the SSDs.

How important are those? Is it worth recreating the RAID1 device or are the performance benefits not really worth it?

I will look at creating a weekly CRON job for TRIM/DISCARD.

My Portage TMPDIR is already on a RAM TMPFS and I plan to move any other frequent I/O location to another (I have plenty of RAM).

Thanks.
Cheers
Ferg
_________________
Climb up it, kayak down it + make sure it runs on GNU/Linux
"cease to exist, giving my goodbye, drive my car into the ocean,
you think I'm dead, but i sail away, on a wave of mutilation!"

NeddySeagoon · Posted: Sat Oct 10, 2020 9:09 am Post subject:

ferg,

You can improve this in a number of ways.
Failing one disk and removing it means you lost redundancy for the rebuild.
You should have added one SSD to the existing raid set, then used the mdadm replace command.
It will use the entire raid as a source to recreate the member to be replaced on the SSD.
No loss of redundancy. It matters when you get a read error during the rebuild.

fdisk will be fine. It has created 4k aligned partitions since soon after Advanted Format rotating rust became a thing.
With UEFI, it moved the default first partition start to 1MiB too, to allow for the partition table.
You can check. if its wrong, it will hurt your write speed and increase your write amplification, which is a bad thing.

Aligning things to the erase block size is nice but not essential. Its very difficult to discover that.

One thing you don't mention.
You should run fstrim in a monthly cron job. Using the discard option to mount is OK if your SSDs implement it properly, many don't, leading to unnecessary erases.

If you don't have aligned partitions, its worth recreating the raid.
If your filesystem block size is smaller than 4k, recreate the filesystem.
For /boot, it won't matter as its rarely written.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

ferg · Posted: Sat Oct 10, 2020 9:26 am Post subject:

As ever many thanks for your insightful comments!

NeddySeagoon · Posted: Sat Oct 10, 2020 9:40 am Post subject:

ferg,

fdisk reserves the space for GPT.
When the drive is partitioned, fdisk does not know how it will be used.

What does

ferg · Posted: Sat Oct 10, 2020 10:06 am Post subject:

NeddySeagoon · Posted: Sat Oct 10, 2020 10:27 am Post subject:

ferg.

Your SSD lies.

ferg · Posted: Sat Oct 10, 2020 10:34 am Post subject:

NeddySeagoon · Posted: Sat Oct 10, 2020 12:52 pm Post subject:

ferg,

That the SSD lies about block sizes is just something to keep in mind.

Partitioning a raid is a bit novel. Its only been supported for a few years.
Personally, I use LVM on top of raid and leave empty unallocated space in the physical volume, which I can allocate later.

For raid metadata=0.90 the metadata is at the end of the raid volume.
For raid metadata=1.2 the metadata is at the start of the raid volume.
We need to know which is in use on /dev/md2, so that we can calculate the on disk layout.

Then you have space for the partition table at the start of the raid.

What does

ferg · Posted: Sat Oct 10, 2020 1:20 pm Post subject:

Thanks.