[dm-crypt] Re: Aligning entire LUKS/LVM/Ext4 filesystem stack to 4K sectors
"Carlos E. R." <[email protected]> Fri, 19 Mar 2021 23:19:42 +0100
| Newsgroups | de.saout.dm-crypt |
|---|---|
| Message-ID | <[email protected]> |
On 19/03/2021 22.39, Johnny Dahlberg wrote: > On 19/03/2021, Carlos E. R. <[email protected]> wrote: >> On 19/03/2021 21.24, Johnny Dahlberg wrote: >>> On 19/03/2021, Maksim Fomin <> wrote: >>>>> On Friday, 19 March 2021 г., 19:09, Johnny Dahlberg <> wrote: >> >> ... >> Related question: >> >> How can one, on an exiting encrypted partition, find out what size is >> using each layer, and if they are aligned or not? >> >> I am using encrypted partitions on SSD and I'm a bit worried. >> >> > > Hello Carlos! > > First you would check the physical sector size of your SSD. It is most > likely 4096 bytes (4K). You can check this by doing: > > cat /sys/block/(the parent device such as nvme0n1)/queue/physical_block_size On the two machines I have running now, both have an nvme system disk, but only one has the encrypted partition on it; both use 512: cer@Telcontar:~> cat /sys/block/nvme0n1/queue/physical_block_size 512 cer@Telcontar:~> Isengard:~ # cat /sys/block/sda/queue/physical_block_size 512 Isengard:~ # Hum! Telcontar:~ # fdisk -l /dev/nvme0n1 Disk /dev/nvme0n1: 465.8 GiB, 500107862016 bytes, 976773168 sectors Disk model: Samsung SSD 970 EVO Plus 500GB 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 Isengard:~ # fdisk -l /dev/sda Disk /dev/sda: 111.8 GiB, 120034123776 bytes, 234441648 sectors Disk model: KINGSTON SMS200S 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 In both cases, the first partition starts on sector 2048. I will look later in my laptop, one has a 1T SSD. > But sometimes the SSD lies and says 512 even though it actually uses > 4096. So if you see 512, do an extra check online. Most likely it is > truly 4096 physically. Could be... I'll check later. > > Next, check the start and end sectors of your partition and make sure > they are both on MiB boundaries, or at least on 4096 byte boundaries. In both cases, the first partition starts on sector 2048. 80035840×512÷4096 = 10004480 80035840×512÷2²⁰ = 39080 so yes :-) > > Next, check LUKS to make sure the "Payload offset" is 2048 or 4096 > waning 1 MiB or 2 MiB respectively): > > sudo cryptsetup luksDump /dev/(your luks device/partition) Isengard:~ # cryptsetup luksDump /dev/sda5 Payload offset: 4096 > > Then check LVM to ensure your physical volume is starting at a > multiple of 1 MiB and that your volume "physical extents" size is a > multiple of 4 MiB: Oh, I'm not using LVM. one step less :-) > sudo pvs -o +pe_start,vg_extent_size,pv_mda_size /dev/mapper/(name of > your LVM physical volume) > > Lastly check your filsystem. If it is ext4, the command to check its > "block size" is: > > sudo tune2fs -l /dev/(your ext4 device) It is XFS. Isengard:~ # xfs_info /dev/mapper/cr_hoard_2 meta-data=/dev/mapper/cr_hoard_2 isize=256 agcount=4, agsize=244172416 blks = sectsz=4096 attr=2, projid32bit=1 = crc=0 finobt=0, sparse=0, rmapbt=0 = reflink=0 data = bsize=4096 blocks=976689664, imaxpct=5 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1 log =internal log bsize=4096 blocks=476899, version=2 = sectsz=4096 sunit=1 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 Isengard:~ # :-) > Good luck! I think I'm good - no worries :-) Thanks! :-) -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar) _______________________________________________ dm-crypt mailing list -- [email protected] To unsubscribe send an email to [email protected]
OpenPGP_signature
(application/pgp-signature, 203 B) - not displayed