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