Re: No space left errors on shutdown with systemd-homed /home dir

[Goffredo Baroncelli <kreijack@libero.it>]

On 31/05/2022 14.44, Colin Guthrie wrote:
> Hi,
> 
> Neal Gompa wrote on 01/02/2022 19:55:
>> On Tue, Feb 1, 2022 at 2:02 PM Colin Guthrie <colin@booksterhq.com> wrote:
>>>
>>> Goffredo Baroncelli wrote on 30/01/2022 09:27:
>>>> On 29/01/2022 19.01, Chris Murphy wrote:
>>>>> On Sat, Jan 29, 2022 at 2:53 AM Goffredo Baroncelli
>>>>> <kreijack@libero.it> wrote:
>>>>>>
>>>>>> I think that for the systemd uses cases (singled device FS), a simpler
>>>>>> approach would be:
>>>>>>
>>>>>>        fstatfs(fd, &sfs)
>>>>>>        needed = sfs.f_blocks - sfs.f_bavail;
>>>>>>        needed *= sfs.f_bsize
>>>>>>
>>>>>>        needed = roundup_64(needed, 3*(1024*1024*1024))
>>>>>>
>>>>>> Comparing the original systemd-homed code, I made the following changes
>>>>>> - 1) f_bfree is replaced by f_bavail (which seem to be more
>>>>>> consistent to the disk usage; to me it seems to consider also the
>>>>>> metadata chunk allocation)
>>>>>> - 2) the needing value is rounded up of 3GB in order to consider a
>>>>>> further 1 data chunk and 2 metadata chunk (DUP))
>>>>>>
>>>>>> Comments ?
>>>>>
>>>>> I'm still wondering if such a significant shrink is even indicated, in
>>>>> lieu of trim. Isn't it sufficient to just trim on logout, thus
>>>>> returning unused blocks to the underlying filesystem?
>>>>
>>>> I agree with you. In Fedora 35, and the default is ext4+luks+trim
>>>> which provides the same results. However I remember that in the past the
>>>> default
>>>> was btrfs+luks+shrunk. I think that something is changed i.
>>>>
>>>> However, I want to provide do the systemd folks a suggestion ho change
>>>> the code.
>>>> Even a warning like: "it doesn't work that because this, please drop it"
>>>> would be sufficient.
>>>
>>>
>>> Out of curiosity (see other thread on the systemd list about this), what
>>> it the current recommendation (by systemd/btrfs folks rather then Fedora
>>> defaults) for homed machine partitioning?
>>>
>>
>> I'd probably recommend Btrfs with the /home subvolume set with
>> nodatacow if you're going to use loops of LUKS backed Btrfs homedir
>> images. The individual Btrfs loops will have their own COW anyway.
>>
>> Otherwise, the Fedora defaults for Btrfs should be sufficient.
> 
> Thought I'd wait for Fedora 36 to be released with everything I need to test this setup.
> 
> Fell at the first hurdle of transferring my data in!
> 
> I transferred a subset of my data (240Gb) onto an external disk and used:
> 
>    homectl with colin -- rsync ...
> 
> 
> The transfer worked but the colin.home file grew to 394Gb. Only about 184Gb used (I presume due to compression).
> 
> Ultimately, this was then unmounted and while it said it could shrink the filesystem with a "Ready to..." message this either didn't happen or the backing file wasn't shrunk to match it. I did receive a message later


I suppose that colin.home is a sparse file, so even it has a length of 394GB, it consumes only 184GB. So to me these are valid values. It doesn't matter the length of the files. What does matter is the value returned by "du -sh".

Below I create a file with a length of 1000GB. However being a sparse file, it doesn't consume any space and "du -sh" returns 0

$ truncate -s 1000GB foo
$ du -sh foo
0	foo
$ ls -l foo
-rw-r--r-- 1 ghigo ghigo 1000000000000 May 31 19:29 foo



> 
> I'm not sure now where it's at with recovery but as nothing is strictly needed to make this work, I think I'll leave my playing with homed there for now and try again at some later date.
> 
> I love the whole idea but it's still a bit to bleeding edge and quirky for my daily driver just yet!
> 
> 
> I've attached various logs in case they are useful (will post separately if the list removes this!)
> 
> 
> Cheers
> 
> Col
> 
> 


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5