You are not logged in.
Pages: 1
Hi all,
Planning to set up an encrypted drive for my new install and can't wrap my head around "optimal logical sector sizes." My goal is to wipe, fully encrypt, and use LVM to partition a 460GB SSD. Its reported physical and logical sector sizes are both 512, which I've read is a standard thing that SSDs do. In checking if this drive has the option to increase its sector size, per this wiki page I ran the following:
hdparm -I /dev/sdbThe relevant lines report:
Logical Sector size: 512 bytes
Physical Sector size: 512 byteswhich I take to mean that I cannot specify a different sector size for this drive. That's fine, and makes enough sense to me, but my followup question is simply, where all of the dm-crypt, LUKS, and LVM pages say to specify the logical sector size as 4KiB, should I just disregard that instruction? My gut is telling me yes, but I don't understand this well enough to really have a complete grasp on what specifying the block size wrong would do, so am erring on the side of caution and posting here. Thanks for helping me out!
Offline
Only few SSDs allow changing their emulated sector size (and out of those, some of them bug out if you do). This something you can consider doing if you're chasing the very last % of possible performance. Which is unlikely your use-case if you're not using NVME. It's not "wrong" to stick to the default the SSD was shipped with.
The 512 byte unit pretty much exists solely for compatibility with bios, partitioning, and the like. Most other storage layers use larger units anyway, that's also why alignment works on the partition level. If filesystems allocated data at random 512-byte offsets, then partition alignment would not help either.
You can set dm-crypt/LUKS to 4K sectors regardless. Just don't expect too much (if any) noticable performance benefits. Some embedded platforms may benefit significantly more than desktop PCs here. Unfortunately 'cryptsetup benchmark' does not cover 512- vs 4096-sector, you'll have to benchmark it yourself.
Note that 4K LUKS only works with aligned partition sizes. If the partition is not multiple of 4096-bytes large, then LUKS will reject the device outright. That's completely a software thing, just how it was designed in the kernel. Something to be aware of when creating/resizing partitions.
So the question is, how much faster would the SSD be when using 4096-emulation instead of 512-emulation, and in case of LUKS how much better would the crypto engine handle 4096 vs. 512 chunks. And does it even become noticable in your use-case?
Offline
Thanks so much for the informative reply! It definitely helped me better understand things here. I went ahead and just sent the defaults for luksFormat, etc, and things seem to be working perfectly fine. You're right that I'm not chasing bleeding edge performance, I just wanted to make use of full-disk encryption on this install. Have had no issues so far, and seems just as fast as the last install I had on this drive, so all is well.
Offline
Pages: 1