>>> Andrii Zymohliad <[email protected]> schrieb am 24.08.2020 um 10:49 in Nachricht <2j3201oowK1vlEa9-nZ6zsUwIuIwqtmetdg1EYSf1Wq1h4SThYqY5IVNEyam4YzS422dZ1TxJJPTRTH [email protected]>: >> 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‑[email protected] > https://lists.freedesktop.org/mailman/listinfo/systemd‑devel _______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
