Model: ATA Samsung SSD 850 (scsi)
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start        End            Size           File system  Name  Flags
 1      24576B       1048575B       1024000B                          bios_grub
 2      1048576B     537919487B     536870912B     fat32              boot, esp
 3      537919488B   1611661311B    1073741824B    zfs
 4      1611661312B  500107845119B  498496183808B  zfs

parted /dev/sda align-check optimal 1
> 1 not aligned
parted /dev/sda align-check optimal 2
> 2 aligned
parted /dev/sda align-check optimal 3
> 3 aligned
parted /dev/sda align-check optimal 4
> 4 aligned

The sector size says 512B, but interally I am guessing 4096B because it is a SSD, either way it should be divisible, 24576 / 512 = 48, 24576 / 4096 = 6. Is there any reason why parted says it is not aligned.

I am aware that this current config should not have any effects on performance as it is only read (if at all) at boot, but just curious in why it is reported as it is.

For reference the partition layout is the one suggested by Debian ZFS on Root (https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Buster%20Root%20on%20ZFS.html)

  • You only needed the bios_grub partition for BIOS/Legacy/CSM boot. If booting with UEFI you do not need it at all. I used to do both when I first started using UEFI as old system was BIOS and might need to move drive. But now only use ESP for new drives. – oldfred Aug 10 '20 at 14:46

Try align-check minimal 1, it should be OK with that.

Irrespective of what parted would consider optimal for your hardware, optimizing the partition layout for flash memory should take into account that chips are organized into pages and erase blocks.

You just cannot simply overwrite a page. The processor controlling the device must first erase it and erasing is only possible in units much larger than the page size.

When the page size for your device is likely to be in the 2KB-32KB range, the erase-block size will typically be somewhere between 128KB and 2MB (64 times more) depending on the capacity of the disk. 4MB is not unusual in the GBs category.

** All operations on the drive can only happen in these units **

=> Forget the page size, open the datasheets of your particular device, find the size of the erase blocks then align your partitions accordingly.

Take care : It was a time when Samsung was playing with very surprising values and not particularly eager to disclose this information.

  • 1
    What is the difference between minimal and optimal ? Thanks! – nehz Aug 10 '20 at 11:45
  • 1
    @nehz : These labels have strictly no meaning outside of parted. In the real life, a partition is aligned or is not. Period. There is nothing... in between. The difference is made by parted. Optimal ? : In any case, that is, irrespective of what the device claims in terms of blocksize / cylinder / heads... you are safe, your partition is aligned. Minimal ? IF the blocksize / cylinder / heads information I get from the device are trustable, then your partition is aligned. If those values a incorrect du to broken hardware... then... your partition won't be aligned. – MC68020 Aug 10 '20 at 16:44
  • 1
    @nehz : However, parted, becaused designed initially for HDDs, always only takes into account the page size. It ignores the erase-block size. But, considering (I think it's the case) that default partition alignement is, for parted, on 1MB boundaries, it is likely to be fair enough for matching a multiple of the erase-block size. – MC68020 Aug 10 '20 at 16:52
  • 1
    @nehz : => As usual : 1/ You get no time to investigate and learn in this area => Follow parted's suggestion. 2/ Parted's suggestions waste a lot of valuable dear space ? You want that space back ? => Learn the specs of your hardware, understand what they mean => tune yourself optimally irrespective of any advice taken from whatever set of default safe value. – MC68020 Aug 10 '20 at 16:56
  • 1
    erase block alignment just isn't a thing. the main factor is still page alignment, and the main issue (before SSDs and 4K sector drives came up) were partitions starting at completely odd sector numbers (sector 63 for windows) because it didn't matter at all before. today you just do MiB alignment and it works for every device (except oddities like HDDs with off-by-one jumpers to make sector 63 aligned). if you want to force erase block alignment anyway, you have a lot of work to do as it's not supported anywhere by default (by partition software, by lvm, filesystems, etc.) – frostschutz Aug 11 '20 at 5:45

It's "not aligned" but it also doesn't matter for the bios_grub partition. Grub only stores a few kilobytes of data there, which is read once when you boot. Align it or not, it will make no difference in practice.

Recent versions of parted may be more verbose about the alignment message:

# parted --version
parted (GNU parted) 3.3
Copyright (C) 2019 Free Software Foundation, Inc.
# parted /dev/loop0 align-check optimal 1
1 not aligned: 48s % 2048s != 0s

So, it's "not aligned" in terms of MiB alignment. It may also not aligned considering that SSDs may use 4K, 8K, 16K pages internally, so 6*4K is a slightly odd value to align to.

The goal in creating the partition this way isn't alignment, instead it's to maximize space usage. Although it's difficult to come up with a use case where Grub would actually need more than just a few sectors.

If you want to "fix" it anyway, you can put the bios_grub partition at offset 1 MiB and have the boot, esp partition start at 2 MiB, leaving the area currently occupied by bios_grub as unpartitioned free space.

But there will be no change in functionality or performance. It's fine to ignore and leave as is.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.