Thank you all for your valuable input.
The current status is, I still use systemd-homed and when it detects that the /home
partition is btrfs, it will automatically create a subvolume (for each user, I only have one) and mount the directory /home/username.homedir
into /home/username
.
This is a directory mount, systemd-homed could also mount a luks or differently encrypted image file which makes more sense than a folder mount.
So, it create a ephemeral mount home-username.mount
which does exactly this.
It also shows up in /proc/mounts
:
grep home /proc/mounts
/dev/mapper/crypthome /home btrfs rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvolid=5,subvol=/ 0 0
/dev/mapper/crypthome /home/username btrfs rw,nosuid,nodev,noatime,idmapped,compress=zstd:3,ssd,discard=async,space_cache=v2,subvolid=5,subvol=/ 0 0
The options in the first row are set by me, the second ones by systemd. There is no home-username.mount
file anywhere. I can only see the specifics with systemctl show home-username.mount
.
Then, the mystery begins.
We have output:
sudo btrfs subvolume show /home
/
Name: <FS_TREE>
UUID: 00487190-dd99-4034-b8c2-01170924c98e
Parent UUID: -
Received UUID: -
Creation time: 2023-03-03 13:23:50 +0100
Subvolume ID: 5
Generation: 935
Gen at creation: 0
Parent ID: 0
Top level ID: 0
Flags: -
Send transid: 0
Send time: 2023-03-03 13:23:50 +0100
Receive transid: 0
Receive time: -
Snapshot(s):
But for the user’s supposed subvolume:
$ sudo btrfs subvolume show /home/username
ERROR: Not a Btrfs subvolume: Invalid argument
However, the subvolume for the archived projects from a few posts before is there:
$ sudo btrfs subvolume show /home/username/archives
username.homedir/archives
Name: archives
UUID: 444be83c-5670-0e41-84f1-c91f2d25e4f8
Parent UUID: -
Received UUID: -
Creation time: 2023-03-03 21:01:41 +0100
Subvolume ID: 256
Generation: 901
Gen at creation: 877
Parent ID: 5
Top level ID: 5
Flags: -
Send transid: 0
Send time: 2023-03-03 21:01:41 +0100
Receive transid: 0
Receive time: -
Snapshot(s):
But I can’t find any information about the mount info, it’s not a systemd-unit or in /proc/mounts
.
As opposed to the discussion above, I think I was able to set the compression level of this subvolume with
$ sudo btrfs property set /home/username/archives compression zstd:9
Which I can verify with:
$ sudo btrfs property get /home/username/archives compression
compression=zstd:9
However, I don’t know if this is overridden by the parent mount or an invalid option.
I did some tests and a 100MB file from here and compressed it with the levels 1, 3, 8, 12, and 19 on a tmpfs:
100.000.000 100M
40.678.709 100M-L1.zst
37.372.605 100M-L2.zst
35.487.160 100M-L3.zst
31.607.256 100M-L8.zst
30.413.324 100M-L12.zst
26.954.633 100M-L19.zst
And to check on btrfs, I copied the file to the /home/username/archives
subvolume and run compsize:
Processed 1 file, 763 regular extents (763 refs), 0 inline.
Type Perc Disk Usage Uncompressed Referenced
TOTAL 39% 39960576 100003840 100003840
zstd 39% 39960576 100003840 100003840
From what I see, it’s closest to compression level 1 when looking closely on the bytes.
So, it is smaller than level 1 but larger than level 2. Shouldn’t it be closer to level 3 if we can cut some slack on overhead? But the property that I’ve set above with using level 9 is surely not applied.