Re: [Help] Can't login to my systemd-homed user account due to fallocate failure

From: Andrei Borzenkov <arvidjaar@gmail.com>
To: Andrii Zymohliad <azymohliad@protonmail.com>,
	Hugo Mills <hugo@carfax.org.uk>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: [Help] Can't login to my systemd-homed user account due to fallocate failure
Date: Sun, 23 Aug 2020 21:16:36 +0300	[thread overview]
Message-ID: <db0c267c-5b8f-067b-673c-8f59002ee48e@gmail.com> (raw)
In-Reply-To: <uE-fvxC5rW1snQPXRetWASSP8a8cJVSTiDa1WNLmtVANT-M_cd6NUZxUlUtLBID2-EBEEJjP0yK7-Knt9-vjWob1dU6H9FE2Dhg0Y1XFOx4=@protonmail.com>

23.08.2020 19:55, Andrii Zymohliad пишет:
> On Sunday, August 23, 2020 7:21 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
>> It's not about LUKS container. systemd tool attempts to reserve full
>> size of image with LUKS inside using fallocate which fails. It never
>> gets as far as actually unlocking it or mounting filesystem inside.
> 
> Yes, thanks Andrei for additional clarification. Here I unlocked and mounted home partition manually just to show what's the state of filesystem on it (I guess that's not important here). Usually, it should be unlocked and mounted by systemd, but it fails because of fallocate failure.
> 
> 
> On Sunday, August 23, 2020 6:37 PM, Hugo Mills <hugo@carfax.org.uk> wrote:
>> The / filesystem is a clear case of needing a data balance. See
>> this link for what to do:
>>
>> https://btrfs.wiki.kernel.org/index.php/FAQ#if_your_device_is_large_.28.3E16GiB.29
>>
>> and see also this link for how to read the data you've pasted here:
>>
>> https://btrfs.wiki.kernel.org/index.php/FAQ#or_My_filesystem_is_full.2C_and_I.27ve_put_almost_nothing_into_it.21
> 
> 
> Thanks for a very quick response and links, Hugo, those are definitely useful for me. But the issue here seems more complicated. I forgot to write about it, but the state of root filesystem differs before and after fallocate attempt (or trying to log in as systemd-homed user).
> 
> Before:
> 
>     # btrfs fi show
> 
>     Label: none  uuid: b68411ce-702a-4259-9121-ac21c9119ddf
>     	Total devices 1 FS bytes used 299.71GiB
>     	devid    1 size 476.44GiB used 301.03GiB path /dev/nvme0n1p2
> 
>     # btrfs fi df /
> 
>     Data, single: total=300.00GiB, used=299.29GiB
>     System, single: total=32.00MiB, used=48.00KiB
>     Metadata, single: total=1.00GiB, used=438.38MiB
>     GlobalReserve, single: total=62.16MiB, used=0.00B
> 
> After:
> 
>     # btrfs fi show
> 
>     Label: none  uuid: b68411ce-702a-4259-9121-ac21c9119ddf
>     	Total devices 1 FS bytes used 299.71GiB
>     	devid    1 size 476.44GiB used 476.44GiB path /dev/nvme0n1p2
> 
>     btrfs fi df /
> 
>     Data, single: total=475.41GiB, used=299.29GiB
>     System, single: total=32.00MiB, used=80.00KiB
>     Metadata, single: total=1.00GiB, used=438.39MiB
>     GlobalReserve, single: total=62.16MiB, used=0.00B
> 
> If I do "btrfs balance start /" it becomes like before fallocate attempt, but it still doesn't fix the issue for me. fallocate and hence "homectl authenticate" would still fail.
> 

Output of "btrfs fi us /" before and after fallocate would probably give
more information. Also "btrfs sub li /" and "btrfs qgroup show -re /"
would be interesting. And "btrfs fi du /home/azymohliad.home".

Rough math so far - filesystem has 175GiB free space. Filesystem inside
container uses 258GiB so assuming container consumes exactly the same
space, in the worst case it needs 145GiB on containing filesystem for
full size. There should be enough free (even unallocated) space. I
thought there could be some snapshots that force btrfs to attempt to
allocate full 403GiB, bit in my testing even after creating read-only
snapshots fallocate does not attempt to duplicate space.