Arch Linux

arch_fuz

Member

Registered: 2015-01-31

Posts: 56

LUKS Container in Logical Volume | Some GB Missing

I have this logical volume:

# lvdisplay --units B  -v /dev/vg0/DataContainer 
  --- Logical volume ---
  LV Path                /dev/vg0/DataContainer
  LV Name                DataContainer
  VG Name                vg0
  LV UUID                hVq7kR-SZcr-tXiE-N7ou-jEY3-KfZe-bHZZrF
  LV Write Access        read/write
  LV Creation host, time xxx, 2020-01-14 22:45:46 +0100
  LV Status              available
  # open                 1
  LV Size                75161927680 B 
  Current LE             17920
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:6

It is mounted like that:

/dev/mapper/vg0-DataContainer on /var/lib/dac type ext4 (rw,noatime,data=writeback)

Inside the mount there are several LUKS-Containers.

It appears to fit inside the LV since it is smaller than the logical volume. du is showing the size of all LUKS containers inside their directory:

# du -sb /var/lib/dac/
71782400000     /var/lib/dac/

One LUKS-Container is this:

#cryptsetup status /dev/mapper/DAC-Backup
/dev/mapper/DAC-Backup is active and is in use.
  type:    LUKS2
  cipher:  aes-xts-plain64
  keysize: 512 [bits]
  key location: keyring
  device:  /dev/loop99
  loop:    /var/lib/dac/DAC-Backup
  sector size:  512 [bytes]
  offset:  32768 [512-byte units] (16777216 [bytes])
  size:    53967232 [512-byte units] (27631222784 [bytes])
  mode:    read/write

df shows this:

# df -a --block-size=M
/dev/mapper/vg0-DataContainer    70248M  68458M        0M  100% /var/lib/dac

df seems right, because I am running out of space when trying to do a particular backup, which should fit.

When I run

# resize2fs /dev/mapper/DAC-Backup
resize2fs 1.47.4 (6-Mar-2025)
File system has 6745904 (4k) blocks already. Nothing to do!

I do not understand why it shows a usage of 100% even there should be storage left. Am I doing wrong calculation?

Could you shed some light on it?

Thanks,
- fuz

-thc

Member

Registered: 2017-03-15

Posts: 1,220

Re: LUKS Container in Logical Volume | Some GB Missing

That looks suspiciously like the 5% (default) that ext4 reserves for "root". Try

tune2fs -m 0 /dev/mapper/DAC-Backup

P.S. If you formatted the loop filesystem with ext4 at it's creation it uses all available blocks (6745904 x 4096 = 27631222784)

arch_fuz

Member

Registered: 2015-01-31

Posts: 56

Re: LUKS Container in Logical Volume | Some GB Missing

Hi.

That looks suspiciously like the 5% (default) that ext4 reserves for "root".

This makes totally sense to me. Even the surrounding container has the reserve mentioned:

# tune2fs -l /dev/mapper/vg0-DataContainer 
tune2fs 1.47.4 (6-Mar-2025)
Filesystem volume name:   <none>
Last mounted on:          /var/lib/dac
Filesystem UUID:          55c308ff-23c5-4989-bcd3-1584c2c509e2
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              4587520
Block count:              18350080
Reserved block count:     896530
Overhead clusters:        366805
Free blocks:              458261
Free inodes:              4587500
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Reserved GDT blocks:      1023
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Tue Jan 14 22:47:24 2020
Last mount time:          Sun Oct 25 18:10:54 2026
Last write time:          Mon Oct 26 10:54:08 2026
Mount count:              343
Maximum mount count:      -1
Last checked:             Tue Jan 14 22:47:24 2020
Check interval:           0 (<none>)
Lifetime writes:          769 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     32
Desired extra isize:      32
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      295bdb95-94ef-4ea7-8204-cf4957c7d763
Journal backup:           inode blocks
Checksum type:            crc32c
Checksum:                 0xd399e172

Reserved block count: 896530 * Block size: 4096 = 3672186880 byte == 5% of total size

Do  you think I can set reserved block count to zero for /dev/mapper/vg0-DataContainer also? Won't there be any negative impacts in that action, i.e. when it comes to resizing (growing)? I do not want to loose my containers

-thc

Member

Registered: 2017-03-15

Posts: 1,220

Re: LUKS Container in Logical Volume | Some GB Missing

Yes - you can tune every ext4 file system (/dev/mapper/vg0-DataContainer) down to 0 % reserved blocks.
I think there is some sense in it - especially for "/":

Reserving some number of filesystem blocks for use by privileged processes is done to avoid filesystem fragmentation, and to allow system daemons, such as syslogd(8), to continue to function correctly after non-privileged processes are prevented from writing to the filesystem.

arch_fuz

Member

Registered: 2015-01-31

Posts: 56

Re: LUKS Container in Logical Volume | Some GB Missing

I have read man tune2fs and exactly the text you quoted made me asking myself if it is a good idea to do so for the containers.
But as far as my knowledge reaches there should be no negative impact to do so for the surrounding container also.

I assume, you see it exactly the same because it is not "/", right?

Thanks for your review and tips!

-thc

Member

Registered: 2017-03-15

Posts: 1,220

Re: LUKS Container in Logical Volume | Some GB Missing

I assume, you see it exactly the same because it is not "/", right?

Yup. I had several cases where the 5% reserve on "/" made an error analysis that much easier (so I keep it) - on data drives I usually set it to 0.