Re: [Help] Can't log in to homed user account: "No space left on device"

[Chris Murphy <lists@xxxxxxxxxxxxxxxxx>]

On Mon, Aug 24, 2020 at 2:44 AM Andrii Zymohliad
<azymohliad@xxxxxxxxxxxxxx> wrote:
>
> > I suspect that the workaround until
> > this is figured out why the fallocate fails (I suspect shared extents,
> > there's evidence this home file has been snapshot and I don't know
> > what effect that has on fallocating the file) is to use
> > --luks-discard=true ? That should avoid the need to fallocate when
> > opening.
>
> Just to confirm, "homectl update --luks-discard=on azymohliad" fixed the issue for me. I can log in again. Thanks a lot to Chris and Andrei!
>
>
> > And the user will have to be vigilant about the space usage
> > of user home because it's now possible to overcommit.
>
> I guess it's better to reduce home size (to something like 300-350G in my case) to decrease the probability of overcommit?
>

Yes. But mainly you'll just want to keep an eye on the underlying file
system free space. If it goes empty, the home file system won't know
this and can try to write anyway, and then we get a pretty icky kind
of failure with the home file system, possibly very bad.

Of course this is a temporary situation, we need to find a long term
solution because it's definitely not intended that the user babysit
the two file systems like this. There should be built-in logic to make
sure It Just Works.

But also in your case you should try to find out why there are shared
extents. That's more of a btrfs question so i'll resume that
conversation on the btrfs list.

-- 
Chris Murphy
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel