Re: geli(8) breaks after a couple hours of uptime

Eitan Adler <lists_at_eitanadler.com> wrote:

> On 8 February 2013 07:46, Andriy Gapon <avg_at_freebsd.org> wrote:
> > on 08/02/2013 13:48 Ulrich Spörlein said the following:

> >> It looks like 128k as a limit is still too low for geli(8) to work, and
> >> I've set it to 256k now, so that I can use "sudo geli". Can you maybe
> >> revise the patch to not use 1024k as an arbitrary limit, but rather make
> >> sure you test for precisely as much memory as will be needed?

IIRC 256K didn't work for me, 512K did, so I doubled it
to have some leg room.

I'm not sure it's possible to reliably estimate the required
memory without first changing geli to mlock less generously,
something Konstantin suggested in:
http://lists.freebsd.org/pipermail/svn-src-all/2013-January/063939.html

While I agree that mlocking less generously would technically be a
better solution than increasing the limit, it would also require a lot
more work, additional audits to make sure it's done correctly and in
case of geli I don't really see a problem with mlocking 1024K for a
few seconds.

> >> Also, can we maybe revisit the new 64k default limit, as it will
> >> obviously make peoples work with geli a bit painful, this should work
> >> out of the box.
> >
> > I have some, IMO, better suggestions:
> > - use -c option with sudo

I usually execute "sudo geli" through a wrapper (zogftw) so this
makes patching geli optional for me. Thanks for mentioning it (again).

> > - tune your system for your needs
> >
> > - [major] abolish the silliness of tying resource limits to login class and apply
> > resource limits based on user and group IDs; including after su/sudo (subject to
> > local policies)

While we are dreaming, it would be nice to have more resource limits
that apply to all the processes belonging to the user combined.

It also wouldn't hurt to document why a 64K per-process limit with an
unlimited number of processes per user is considered a good default in
the first place.

> The default settings should not make another feature unusable.  At a
> minimum it should be documented in geli's man page that such tuning is
> required.

If the consensus is that 1024K are too much for geli and nobody can
be bothered to come up with a more fine grained mlocking patch,
geli could be changed to check the mlock limit and exit with a
useful error message if it's too low.

This would at least prevent the segfault.

Fabian