[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-btrfs
Subject:    Re: No space left errors on shutdown with systemd-homed /home dir
From:       Colin Guthrie <gmane () colin ! guthr ! ie>
Date:       2022-06-01 9:36:11
Message-ID: t77bub$vp5$1 () ciao ! gmane ! io
[Download RAW message or body]

Goffredo Baroncelli wrote on 31/05/2022 19:12:
> 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

Yeah the file will be sparse.

That's not really an issue, I'm not worried about the fact it's not 
consuming as much as it reports as that's all expected.

The issue is that systemd-homed (or btrfs's fallocate) can't handle this 
situation and that user is effectively bricked unless migrated to a host 
with more storage space!

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
   Tribalogic Limited http://www.tribalogic.net/
Open Source:
   Mageia Contributor http://www.mageia.org/
   PulseAudio Hacker http://www.pulseaudio.org/
   Trac Hacker http://trac.edgewall.org/

[prev in list] [next in list] [prev in thread] [next in thread]