Re: [dm-crypt] crypetsetup and GPT partitions

[Sven Eschenberg <sven@whgl.uni-frankfurt.de>]

Am 10.02.2017 um 19:23 schrieb David Christensen:
> On 02/10/17 08:22, Sven Eschenberg wrote:
>> Am 10.02.2017 um 17:05 schrieb David Christensen:
>>> On 02/10/17 01:07, Michael Kjörling wrote:
>>>> On 10 Feb 2017 00:15 -0800, from dpchrist@holgerdanske.com (David
>>>> Christensen):
>>>>> The available space of the LUKS mapped device is going to be smaller
>>>>> than the partition size.  On one of my 3 TB drives, it's about ~44
>>>>> GB smaller (~1.6%).  The LUKS meta-data is going to be in there,
>>>>> including the header.
>>>>
>>>> That doesn't make sense. The LUKS header is a shade over 1 MiB,
>>>> depending on the specific options (the FAQ has details). The size of
>>>> the header isn't related to the size of the container. Something else
>>>> is going on in your case.
>>>
>>> Here's the data:
>>>
>>> 2017-02-10 07:38:40 root@cd2533 ~
>>> # parted /dev/sda u s p
>>> Model: ATA ST3000DM001-1ER1 (scsi)
>>> Disk /dev/sda: 5860533168s
>>> Sector size (logical/physical): 512B/4096B
>>> Partition Table: gpt
>>>
>>> Number  Start  End          Size         File system  Name     Flags
>>>  1      2048s  5860532223s  5860530176s               primary
>>>
>>> 2017-02-10 07:40:57 root@cd2533 ~
>>> # df | egrep 'File|mnt'
>>> Filesystem                1K-blocks      Used  Available Use% Mounted on
>>> /dev/mapper/i3000d_crypt 2884281560 848596104 1889172304  31%
>>> /mnt/i3000d
>>>
>>>
>>> Here's the math:
>>>
>>>    5860530176 s / (2 s/kB) - 2884281560 kB
>>>  = 2930265088 kB           - 2884281560 kB
>>>  = 45983528 kB
>>> ~= 44905.8 MB
>> That's the size of the filesystem afterall.
>
> D'oh!
>
>
>> Lookt at blockdev --report to see the blockdev sizes (i.e. physical
>> disk, partition, crypt device).
>
>
> RTFM blockdev(8):
>
> 2017-02-10 10:01:08 root@cd2533 ~
> # blockdev --report /dev/sda /dev/sda1 /dev/mapper/i3000d_crypt
> RO    RA   SSZ   BSZ   StartSec            Size   Device
> rw   256   512  4096          0   3000592982016   /dev/sda
> rw   256   512  4096       2048   3000591450112   /dev/sda1
> rw   256   512  4096          0   3000589352960   /dev/mapper/i3000d_crypt
>
>
> So, it looks like LUKS consumes:
>
> 3000591450112 - 3000589352960 = 2097152 = 2 MB
>
>
> Thanks for the correction.  :-)
>
>
>> Check against dmsetup
>
> RTFM dmsetup(8):
>
> 2017-02-10 10:14:06 root@cd2533 ~
> # dmsetup info /dev/mapper/i3000d_crypt
> Name:              i3000d_crypt
> State:             ACTIVE
> Read Ahead:        256
> Tables present:    LIVE
> Open count:        1
> Event number:      1
> Major, minor:      254, 2
> Number of targets: 1
> UUID: CRYPT-LUKS1-<redacted>-i3000d_crypt_unformatted
>
>
>> --table
>
> RTFM dmsetup(8), the --table option requires a <table> value.  WAG:
>
> 2017-02-10 10:14:17 root@cd2533 ~
> # dmsetup info --table LIVE /dev/mapper/i3000d_crypt
> Name:              i3000d_crypt
> State:             ACTIVE
> Read Ahead:        256
> Tables present:    LIVE
> Open count:        1
> Event number:      1
> Major, minor:      254, 2
> Number of targets: 1
> UUID: CRYPT-LUKS1-<redacted>-i3000d_crypt_unformatted
>
>
> I'm not sure what I am checking...

My bad, it is just dmsetup table - this dumps all (active) devicemapper 
targets with all essential data ... you can basically take a look at 
where in the drive a mapping starts, how long it is etc. . The output 
includes the key for crypt targets and whatever additional data each 
type of target offers. It sometimes helps to understand the exact layout 
better (You'll need to know/understand those numbers however). Just in 
case you think you hit some inconsistency or the like. No need however 
to post it here.
>
>
> David
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

As you know by now, the size of the crypto target (the device size 
available to the filesystem) is just 2MBytes less than the partition 
size. So maybe check again on the filesystem size (use the corresponding 
filesystem tools if necessary). If you did not increase the device size 
at any time after fs creation, then somehow your mkfs did something 
wrong. Depending on the fs, if you have a backup of the data, you could 
try growing the fs to the full size of the container.

Regards

-Sven

P.S.: Usually df reports the available space to files AFAIK, this should 
be roughly devicesize-metadatasize, where metadata is internal 
filesystem structures but not filenames and the like (inode space). But 
I cannot tell for 100%. I.E.: for a 16GB filesystem I have a difference 
of roughly 10 MBytes. (Depends certainly on the filesystem used ...)