bcachefs CLI: question on use of mlockall()

bcachefs CLI: question on use of mlockall()

[Thomas Bertschinger]

The mlockall(MCL_FUTURE) call at the beginning of the bcachefs CLI
tool seems problematic in some cases. When running commands as an
unprivileged user with the default mlock limit (8 MiB), it can cause
ENOMEM failures, for example:

$ ulimit -l
8192
$ fallocate -l $((1024 ** 3)) test-image
$ bcachefs format test-image
...
error opening test-img: ENOMEM_fs_other_alloc


While this can be worked around by running the bcachefs utility as
root, or by raising the default limit, I think commands like this
should work for unprivileged users under a common default configuration.

I wonder if the mlockall() can be targeted to the scenarios where it's
really needed, instead of applying to every bcachefs command? Some
ideas on how to target it: 
- only call it if running as root
- check that getrlimit(RLIMIT_MEMLOCK, ...) is at a "high enough" value
first
- or, only call it for subcommands that actually need it

Any thoughts / comments? Would a better, or complementary approach, be
to reduce the amount of memory mapped for operations like 'format'?

Thanks!

- Thomas Bertschinger

Re: bcachefs CLI: question on use of mlockall()

[Kent Overstreet]

On Mon, Dec 18, 2023 at 09:07:47PM -0700, Thomas Bertschinger wrote:
> The mlockall(MCL_FUTURE) call at the beginning of the bcachefs CLI
> tool seems problematic in some cases. When running commands as an
> unprivileged user with the default mlock limit (8 MiB), it can cause
> ENOMEM failures, for example:
> 
> $ ulimit -l
> 8192
> $ fallocate -l $((1024 ** 3)) test-image
> $ bcachefs format test-image
> ...
> error opening test-img: ENOMEM_fs_other_alloc
> 
> 
> While this can be worked around by running the bcachefs utility as
> root, or by raising the default limit, I think commands like this
> should work for unprivileged users under a common default configuration.
> 
> I wonder if the mlockall() can be targeted to the scenarios where it's
> really needed, instead of applying to every bcachefs command? Some
> ideas on how to target it: 
> - only call it if running as root
> - check that getrlimit(RLIMIT_MEMLOCK, ...) is at a "high enough" value
> first
> - or, only call it for subcommands that actually need it
> 
> Any thoughts / comments? Would a better, or complementary approach, be
> to reduce the amount of memory mapped for operations like 'format'?

Perhaps it's time to delete it, since our run_shrinkers() path is now
also considering swap usage?

The idea was that we really don't want to be swapping, since generally
memory usage will be dominated by caches that we can evict from - we
would rather have the mmeory allocation fail instead.

But I think we can just delete it if it's not working properly, since we
also have shrinkers running in the background via a thread too.