Re: [PATCH v3 0/3] shmem: Allow userspace monitoring of tmpfs for lack of space.

[Gabriel Krisman Bertazi <krisman@collabora.com>]

Amir Goldstein <amir73il@gmail.com> writes:

> On Tue, Apr 19, 2022 at 6:29 PM Gabriel Krisman Bertazi
> <krisman@collabora.com> wrote:
>> > Well that sucks.  We need a kernel-side workaround for applications
>> > that fail to check and report storage errors?
>> >
>> > We could do this for every syscall in the kernel.  What's special about
>> > tmpfs in this regard?
>> >
>> > Please provide additional justification and usage examples for such an
>> > extraordinary thing.
>>
>> For a cloud provider deploying containerized applications, they might
>> not control the application, so patching userspace wouldn't be a
>> solution.  More importantly - and why this is shmem specific -
>> they want to differentiate between a user getting ENOSPC due to
>> insufficiently provisioned fs size, vs. due to running out of memory in
>> a container, both of which return ENOSPC to the process.
>>
>
> Isn't there already a per memcg OOM handler that could be used by
> orchestrator to detect the latter?

Hi Amir,

Thanks for the added context.  I'm actually not sure if an OOM handler
completely solves the latter case.  If shmem_inode_acct_block fails, it
happens before the allocation. The OOM won't trigger and we won't know
about it, as far as I understand.  I'm not sure it's real problem for
Google's use case.  Khazhy is the expert on their implementation and
might be able to better discuss it.

I wanna mention that, for the insufficiently-provisioned-fs-size case,
we still can't rely just on statfs.  We need a polling interface -
generic or tmpfs specific - to make sure we don't miss these events, I
think.

Thanks,

-- 
Gabriel Krisman Bertazi