On 14/08/17 01:58 PM, Pascal Hambourg wrote:
That still sounds like a bug. If I did a DD from a smaller to a larger hard disk then used gdisk, I'd expect it to see the new drive size and handle it correctly. In fact it did notice that the md array was larger but didn't update its tables.Le 14/08/2017 à 06:32, Gary Dale a écrit :Disk /dev/md1: 39068861440 sectors, 18.2 TiB Logical sector size: 512 bytes Disk identifier (GUID): EFF29D11-D982-4933-9B57-B836591DEF02 Partition table holds up to 128 entries First usable sector is 34, last usable sector is 31255089118^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^You created a GPT partition table on the md array. When the table is created, the first and last usable sector numbers (depending on the device size at creation time) are recorded in the GPT header and define the total available space. The reason is because before the first available sector and after the last available sector are the two copies of the partition table. So changing the device size is not enough : you need to move the secondary partition table at the new end and adjust the last usable sector number.
Again, gdisk does appear to know that the device is larger than its tables indicate but doesn't update its tables. At the very least, I'd expect it to produce a message telling me about the issue and suggesting a resolution the way gparted did.Neither fdisk nor gdisk let me create a partition larger than the existing one. Nor do they let me create a new partition anywhere except in the first 2047 sectors.Because they rely on the GPT header to determine the available space.With gdisk you could have used the "v" command to verify the disk and adjust the partition table to the new size. I don't know if fdisk can do it too.
The reason its rare is more likely that Linux hasn't been able to boot from mdadm partitions until recently. I'm one of those people who see little value in LVM. It just adds complexity without doing anything that a little planning could usually avoid. Of course, I'm not running a large datacentre with the need to frequently reallocate disk space on the fly...I'm not sure what the problem is that gparted was able to see but fdisk and gdisk couldn't and whether this is a bug in mdadm or something else, but I thought I should report it somewhere.In the first place, the bug was to create a partition table on an md array. Almost nobody does this and I can see no value in doing it. It is useless. If you want to use the whole array as a single volume, don't partition it. If you want to create multiple volumes, use LVM as most people still do even after md arrays could be partitioned. It is much more flexible than partitions.
For me, booting from a partitioned RAID array makes more sense. It adds no extra programs that can be hacked and that add to the system overhead while still allowing me to divide up the available disk space as if it were a single drive.
Creating multiple RAID arrays seems like the less desirable solution since they'd either require more drives or make resizing more complicated (depending on whether you were creating one array per group of drives or multiple arrays on each group of drives).
Being old school, I also note that the RAID controllers from the 1990s did pretty much the same thing. You'd create the arrays on a bunch of disks through the controller utility then use the OS to partition the arrays.