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

["Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx>]

>>> Andrii Zymohliad <azymohliad@xxxxxxxxxxxxxx> schrieb am 24.08.2020 um 10:49
in
Nachricht
<2j3201oowK1vlEa9-nZ6zsUwIuIwqtmetdg1EYSf1Wq1h4SThYqY5IVNEyam4YzS422dZ1TxJJPTRTH
fPWGpO8A9zyLz8HeLkF_xPfWhI8=@protonmail.com>:
>>  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?

Actually I think separating system and user data is important: If your OS
upgrade went wrong and you want to revert to the previous OS version via
snapshot, you typically do not want to revert the user data as well. Or the
other way 'round.
Despite of that you probably don't want a user to fill up the whole root
filesystem, possibly preventing logins.
If you don't want to use quotas, I'd use separate partitions or logival
volumes...

> 
> _______________________________________________
> systemd‑devel mailing list
> systemd‑devel@xxxxxxxxxxxxxxxxxxxxx 
> https://lists.freedesktop.org/mailman/listinfo/systemd‑devel 



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