doc: Add notes on how GPT works on 4k sector disks.

I used scsi_debug to create a 4k sector virtual disk:

  modprobe scsi_debug dev_size_mb=128 sector_size=4096

I then used 'gdisk' to create lots of partitions, and used 'hexdump'
to examine what was written to disk.

2 files changed, 16 insertions, 3 deletions

diff --git a/daemon/parted.c b/daemon/parted.c
index 26100422..1a020f9b 100644
--- a/daemon/parted.c
+++ b/daemon/parted.c
@@ -199,7 +199,9 @@ do_part_disk (const char *device, const char *parttype)
    *
    * - aligned operations are faster
    * - absolute minimum recommended alignment is 64K (1M would be better)
-   * - GPT requires at least 34 sectors at the end of the disk.
+   * - GPT requires at least 34 sectors* at the end of the disk.
+   *
+   *   *=except for 4k sector disks, where only 6 sectors are required
    */
   const char *startstr = "128s";
   const char *endstr = "-128s";
diff --git a/resize/resize.ml b/resize/resize.ml
index 256148d3..e8187c89 100644
--- a/resize/resize.ml
+++ b/resize/resize.ml
@@ -866,8 +866,19 @@ let () =
     let start =
       if parttype <> GPT then 512L
       else
-        (* XXX With 4K sectors does GPT just fit more entries in a
-         * sector, or does it always use 34 sectors?
+        (* With 512 byte sectors, GPT looks like:
+         *    512 bytes   sector 0       protective MBR
+         *   1024 bytes   sector 1       GPT header
+         *  17408 bytes   sectors 2-33   GPT entries (up to 128 x 128 bytes)
+         *
+         * With 4K sectors, GPT puts more entries in each sector, so
+         * the partition table looks like this:
+         *   4096 bytes   sector 0       protective MBR
+         *   8192 bytes   sector 1       GPT header
+         *  24576 bytes   sectors 2-5    GPT entries (up to 128 x 128 bytes)
+         *
+         * qemu doesn't support 4k sectors yet, so let's just use the
+         * 512 sector number for now.
          *)
         17408L in