[chbot] Urgent help with disk partitioning

[Volker Kuhlmann]

On Thu 20 Jul 2023 10:37:52 NZST +1200, Robin Gilks wrote:

> I'm replacing a failed disk in my raid array

General reply.

I avoid GUI disk partition stuff because I don't trust it telling
me exactly what's going on. I never had a use for parted.

There was a time when fdisk couldn't handle GPTs and gdisk was needed.
fdisk has now acquired that functionality so that's all you need.

When you create disk partitions and raid arrays make some careful notes
about the parititon boundaries and array configuration, should you ever
be in your present situation... It amounts to redirecting output of some
programs (fdisk -l, mdadm with different options) to files. Remember on
Linux you can always recover damaged partition tables and not lose the
filesystem, *if* you know the block numbers. Any partitioning tool also
creating filesystems unless explicitly told (fdisk, gdisk, sfdisk etc
aren't able to) needs to be deleted now.

Do yourself a favour and make separate arrays for system, home, and
data. Or at least for system.

Depending on your disks, it might be useful to know that constituent
partitions do not need to start at the same block numbers. Mirror sda2
with sdc6 if it suits.

All assuming Linux softraid. I wouldn't consider anything else, unless
it's a proper hardware-raid controller card. I think they're $k.
Anything around $100 (used to be common) makes you worse off, it's
propriatary rubbish for no performance gain. Card dies, buy exact same
model or data gone. That stuff is integrated in better mobos these days,
waste of silicon. Dead mobo, dead data.

Be careful with consumer disks in RAID arrays. There are plenty of
warnings online, relating to response times being taken as dead disk,
and random read errors (likely with today's TB disks) taking the disk
out of the array and combined with other factors creating a
non-recoverable situation (data gone).

I ignored that, so far, so mostly good. For the past 4 years I've used
ST4000DM004, WD40EZRZ, and a top-end SSD (Samsung 970 Evo Plus) in
RAID1. It worked perfectly until an OS upgrade late last year, and it
took me months to find out why something in the system was going like
treacle (e.g. 1-2s delay for less to exit in a terminal). The problem
disappeared once I took the ST4000DM004 out of the array (its SMART
status is perfect) so I see Seagate STx000DM as useless for arrays. The
nuisance is that better disks are noisier.

Never use disks from the same batch in a RAID array... and ST2000DM were
rubbish and dies around warranty time.

Back to your problem, DOS partition tables are good for 2^32 block or
2TB disks. Larger requires GPT, which creates some dummy DOS table to
fool tools into thinking there is a table present (there is, it's just
GPT, but the old tools don't get that).

If you have an old Linux and your fdisk doesn't do GPT, use gdisk. It
works basically like fdisk. To add a clean disk to your array, create
partitions of the same size as the others in the array. Remember that
the partition is a few kb larger than the filesystem - RAID superblock,
and there are options for its location. Your mdadm will take care of
that. Create the partition layout, mark the partition as raid type
(potentially optional), make the kernel reload the disk table after
change (or reboot), and use mdadm to add the empty/unformatted
partitions to the array.

Check rebuild status etc with cat /proc/mdstat

Bonus for doing all that with LVM and encrypted disks and partitions in the
mix...

Volker

-- 
Volker Kuhlmann
http://volker.top.geek.nz/	Please do not CC list postings to me.