According to the cryptsetup(8) man page, the sector size of a LUKS2 volume may be configured with --sector-size:

Set sector size for use with disk encryption. It must be power of two and in range 512 - 4096 bytes. The default is 512 bytes sectors. This option is available only in the LUKS2 mode ... Increasing sector size from 512 bytes to 4096 bytes can provide better performance on most of the modern storage devices and also with some hw encryption accelerators.

The default sector size of 512 bytes was kept essentially for compatibility reasons. According to the release notes for cryptsetup 2.0.0, the sector size is stored in metadata and cannot be changed later. So, migrating my existing LUKS2 volumes to 4K sectors will be time-consuming.

How much do 4K sectors improve LUKS2 performance on SSD storage? What encryption hardware is best able to take advantage of 4K sectors?

  • 1
    I tried to benchmark it on low-end consumer hardware (Crucial SATA SSD, Intel Haswell CPU, ...) and it does not seem to make any difference whatsoever for both linear and random 4K read tests. But I'm not sure if that's because AESNI does anything different for 4K sectors or if my consumer SSD is just too slow to make a difference... Commented Nov 28, 2020 at 11:56
  • @frostschutz try testing in tmpfs but again I think the performance difference will be close to zero Commented Nov 28, 2020 at 12:55
  • maybe related, lore.kernel.org/linux-crypto/… Commented Nov 28, 2020 at 14:04
  • Older info, but still valid: developer.ibm.com/tutorials/l-4kb-sector-disks
    – oldfred
    Commented Nov 28, 2020 at 16:14

2 Answers 2


On SSD impact of using 512 sectors with LUKS instead of 4K can slow down read/write operations on a fast SSD by a few percent. F2FS and XFS are particularly vulnerable, see, for example reddit discussion.


How much do 4K sectors improve LUKS2 performance on SSD storage?

Linux by default operates with memory using 4K pages, so naturally 4K sectors imply less resources spent on dealing with encrypted storage. I assume the difference between 512 and 4096 sectors will be minuscule.

What encryption hardware is best able to take advantage of 4K sectors?

Pretty much all the x86 CPUs released in the past 10 years support HW accelerated AES encryption/decryption. Newer ARM CPUs support it as well.

Run this to check whether your CPU is capable:

grep -qw -m1 aes /proc/cpuinfo && echo "HW AES encryption/decryption are supported" || echo "No AES acceleration support"
HW AES encryption/decryption are supported
  • Thank you for answering. Given the block size in AES is fixed at 128 bits (and cryptsetup's default --cipher is aes-xts-plain64), I'm confused as to how increasing the LUKS2 sector size to 4096 bytes could improve hardware-accelerated encryption performance ...
    – sjy
    Commented Nov 28, 2020 at 11:41
  • @sjy It's very logical: You tell the AES-NI instruction "Here's the key, here's the data, please decode it" and the hardware then goes through every byte and decrypts it and returns the result. With 4096 byte chunks, you get 8x more work done per CPU instruction call than if you called it 8x for eight separate 512 byte chunks. Easy. That is why it's faster. It's also less interrupts/queueing for the kernel! I wouldn't go above 4096 though, because 4096 bytes per encrypted chunk fits perfectly with the Linux page size and with the typical filesystem block size of 4096 bytes per block. Commented Mar 22, 2021 at 14:37
  • @sjy Furthermore, as lore.kernel.org/linux-crypto/… points out, the dm-crypt engine is sequential and handles 1 single block at a time. So the more data each block contains, the less overhead/wasted time from constantly waiting for dm-crypt to provide the next block of data to the hardware AES-NI decryptor. Commented Mar 22, 2021 at 14:45
  • @sjy In fact, I see that dm-crypt only allows 512, 1024, 2048 and 4096 as its encrypted sector sizes. They wisely stopped at 4096, probably for the reasons I mentioned in the previous comment. Commented Mar 22, 2021 at 14:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .