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

[Chris Murphy <lists@xxxxxxxxxxxxxxxxx>]

On Sun, Aug 23, 2020 at 6:47 AM Andrei Borzenkov <arvidjaar@xxxxxxxxx> wrote:
>
> 23.08.2020 15:34, Andrii Zymohliad пишет:
> >> Here is the log after authentication attempt: https://gitlab.com/-/snippets/2007113
> >> And just in case here is the full log since boot: https://gitlab.com/-/snippets/2007112
> >
> > Sorry, links are broken, re-uploaded:
> >
> > Authentication part: https://gitlab.com/-/snippets/2007123
> > Full log: https://gitlab.com/-/snippets/2007124
> >
>
> Yes, as suspected:
>
> > сер 23 14:12:48 az-wolf-pc systemd-homed[917]: Not enough disk space
> to fully allocate home.
>
> This comes from
>
>         if (fallocate(backing_fd, FALLOC_FL_KEEP_SIZE, 0, st->st_size) <
> 0) {
>
> ...
>                 if (ERRNO_IS_DISK_SPACE(errno)) {
>                         log_debug_errno(errno, "Not enough disk space to
> fully allocate home.");
>                         return -ENOSPC; /* make recognizable */
>                 }
>
>                 return log_error_errno(errno, "Failed to allocate
> backing file blocks: %m");
>         }
>
> So fallocate syscall failed. Try manually
>
> fallocate -l 403G -n /home/azymohliad.home
>
> if it fails too, the question is better asked on btrfs list.

User reports this from 'homectl inspect'

LUKS Discard: online=no offline=yes

Does this mean 'fstrim' is issued before luksClose? And 'fallocate' is
issued before luksOpen?

If so, it seems it'd be trivial to run into a fatal attempt to
activate, just by deactivating a user home of default size. And then
consuming free space on the underlying volume, such that there isn't
enough free space to fallocate the home file before opening it again.
What am I missing?

What it seems homed needs to do if fallocate fails for whatever reason
is to have some kind of fallback. Otherwise the user is stuck being
unable to open their user home. 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. And the user will have to be vigilant about the space usage
of user home because it's now possible to overcommit.



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