2

I am trying to get sgdisk to create partitions that align on 1 MB.

This is easy for the starting sector (using -a), and for the ending sector, if I choose the size.

But if I let sgdisk choose the ending sector I end up with something like:

Device                                                         Start       End   Sectors   Size Type
/dev/disk/by-id/scsi-36848f690d917dc002587bfae06302a5a-part2    2048   1046527   1044480   510M EFI System
/dev/disk/by-id/scsi-36848f690d917dc002587bfae06302a5a-part3 1048576   5242879   4194304     2G Solaris /usr & Apple Z
/dev/disk/by-id/scsi-36848f690d917dc002587bfae06302a5a-part4 5242880 467660800 462417921 220.5G Linux filesystem

And a size of 462417921 is clearly not aligned to a 1 MB block.

I would have expected something like:

/dev/disk/by-id/scsi-36848f690d917dc002587bfae06302a5a-part4 5242880 466616319 461373440 220G Linux filesystem

It seems -a only applies to the starting sector.

How can I make it align the ending sector, too, for the rest-of-the-disk partition?

The partition table is made with:

sgdisk --zap-all $DISK
sgdisk            -n2:1M:+510M    -t2:EF00 $DISK
sgdisk -a 1048576 -n3:0:+2G       -t3:BF01 $DISK
# Use the rest of the disk for the final partition
# and it is here the end sector is not aligned
sgdisk -a 1048576 -n4:0:-0        -t4:BF01 $DISK
Ole Tange
  • 33,591
  • 31
  • 102
  • 198
  • @frostschutz Updates with exact commands. – Ole Tange Jun 09 '20 at 16:42
  • @frostschutz "like already mentioned, it's not important for alignment." I really do not know where you get that misinformation from. Set up a LUKS device on a partition with an odd number of sectors, if you do not believe me. It makes 100% difference. I have the feeling you simply never tried that and thus you speak of something you have no experience with. Am I right? – Ole Tange Jun 09 '20 at 19:54
  • @frostschutz Can you confirm that you have actually tested? Or are you only theorizing here? (Because I have tested, and you are wrong: If your partition is an odd number of sectors you are screwed when using LUKS). – Ole Tange Jun 09 '20 at 20:20
  • Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/109126/discussion-between-ole-tange-and-frostschutz). – Ole Tange Jun 09 '20 at 20:43
  • You can force the partition end to be aligned by passing `-I` in addition to `-a` – carpii Apr 17 '23 at 12:04

2 Answers2

2

This is a very unusual requirement and doesn't really fit with the intended use case of the sgdisk alignment option:

-a, --set-alignment=value

Set the sector alignment multiple. GPT fdisk aligns the start of partitions to sectors that are multiples of this value, which defaults to 2048 on freshly formatted disks. This alignment value is necessary to obtain optimum performance with Western Digital Advanced Format and similar drives with larger physical than logical sector sizes, with some types of RAID arrays, and with SSD devices.

The end sector of your partition will not have the performance implications that the start sector does. Which is why the -a switch doesn't affect the end sector.

Perhapse your best option is to use the -E option to find out what -nx:x:0 would do and then calculate the alignment for yourself:

man 8 sgdisk

-E, --end-of-largest Displays the sector number of the end of the largest available block of sectors on the disk. A script may store this value and pass it back as part of -n's option to create a partition. If no unallocated sectors are available, this function returns the value 0.

So to use this in a script (eg bash script) you would do this:

end_position=$(sgdisk -E $DISK)
sgdisk -a 1048576 -n4:0:$(( $end_position - ($end_position + 1) % 2048 ))   -t4:BF01 $DISK

Here the script creates the partition with an explicitly set end sector which will be as close to the end of the disk as possible but aligned to 1048576 bytes (1MiB).

Philip Couling
  • 17,591
  • 5
  • 42
  • 82
  • If you think "will not have the performance implications" then you need to try setting up LUKS on such a device. It *REALLY* matters a lot. It is the difference between having a useful and a useless system. Try it if you do not believe me. – Ole Tange Jun 09 '20 at 19:47
  • @OleTange Please confirm I read that right. You are saying that LUKS encrypted partitions perform badly if their end is not aligned to 1MiB? LUKS uses block level encryption so the end should only affect performance of the last block. What file system are you using over LUKS? That may make a segnificant different if for some reason that FS is hammering the last block. – Philip Couling Jun 09 '20 at 20:08
  • Yes. Test it out if you do not believe me. You get 100% degradation: It simply does not work. – Ole Tange Jun 09 '20 at 20:17
  • You do not get to that: It does not work. I think it is easier for you to test it yourself than for me to explain it in a comment. – Ole Tange Jun 09 '20 at 20:43
  • 1
    @OleTange You don't seem to be describing a performance issue. It sounds like compatibility issue. Either way I can't reproduce it. I've created a loop device exactly `819103 * 512` bytes large. Then executed `cryptsetup luksFormat` followed by `cryptsetup luksOpen`. Both succeed. Then formatted with ext4 and mounted. Both succeed. Finally I've tried generating random files and reading back their contents. No errors or loss of fidelity. Glad my answer could help you anyway. – Philip Couling Jun 09 '20 at 22:04
0

You're seemingly trying to solve an issue which you don't have or don't really understand. The requirement to align partitions applies only to the partition start.

Here's my perfectly aligned partition table:

Disk /dev/sda: <skipped>
Disk model: <skipped>
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: <skipped>

Device         Start       End   Sectors   Size Type
/dev/sda1       2048    206847    204800   100M EFI System
/dev/sda2     206848    468991    262144   128M Linux filesystem
/dev/sda3     468992  67577855  67108864    32G Linux filesystem
...

Notice how the end sectors are all "unaligned".

Artem S. Tashkinov
  • 26,392
  • 4
  • 33
  • 64
  • Notice how all your end sectors are odd. My last one is even. All your sizes are divisible by 8192. The size of my last one is odd. Do you understand the problem now? – Ole Tange Jun 09 '20 at 16:24
  • This answer is a bit confusing. In answer to a "How to" it is suggesting "you don't need to". But it is then wrong about the end alignment. Only the last end sector is "unaligned". The rest are all aligned such that they *end* on a MiB boundary. To check: `(END + 1) * 512` Must be divisible by `1024 * 1024` – Philip Couling Jun 09 '20 at 17:03