Re: Aligning entire LUKS/LVM/Ext4 filesystem stack to 4K sectors

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]