On Saturday, January 27, 2024 at 04:08:21 AM EST, Pascal Hambourg [off-list ref] wrote:

You should be able to rebuild the array on top of the partitions by
subtracting the partition offset from the data offset. If the partitions
all begin at sector 2048:

--data-offset=$((262144-2048))s

Thanks.  I might try that after I get the new drive... and back everything up.

Beware that /dev/sd* names are not always persistent across reboots, so
check that the disks are in the same order as during the previous boot.

Yeah, so far I haven't had that problem, but I do know it's possible. 

RAID5 provides disk fault tolerance. If you only need disk aggregation,
you could use RAID0 or LVM instead.

Well the original reason for this array when I built it was that huge drives, like 12 TB (the effective capacity of the array), weren't affordable, if they were available at all.  That's the point I was trying to make - the need for an array to get 12 TB of storage has gone by the wayside; I can just buy 12 TB drives.  I have no plan to move away from the array for now, though, I figure I'll keep using it until drives start dying or I truly fill it up, then decide.

Thanks.
--RJ



On 27/01/2024 at 00:45, RJ Marquette wrote:

Quick follow up:  When I rebooted, the partition tables got munged
again.  Definitely a BIOS issue.  I have a 10TB drive on order, so I'll
copy everything off, then rebuild the array in the recommended format
with partitions, and see what happens then

You should be able to rebuild the array on top of the partitions by 
subtracting the partition offset from the data offset. If the partitions 
all begin at sector 2048:

--data-offset=$((262144-2048))s

Beware that /dev/sd* names are not always persistent across reboots, so 
check that the disks are in the same order as during the previous boot.

(though one wonders if I even need an array when a single drive can
hold everything...).

RAID5 provides disk fault tolerance. If you only need disk aggregation, 
you could use RAID0 or LVM instead.