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

From: Gabriel Krisman Bertazi <krisman@collabora.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: hughd@google.com, amir73il@gmail.com, viro@zeniv.linux.org.uk,
	kernel@collabora.com, Khazhismel Kumykov <khazhy@google.com>,
	Linux MM <linux-mm@kvack.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH v3 0/3] shmem: Allow userspace monitoring of tmpfs for lack of space.
Date: Tue, 19 Apr 2022 11:28:56 -0400	[thread overview]
Message-ID: <87h76pay87.fsf@collabora.com> (raw)
In-Reply-To: <20220418204204.0405eda0c506fd29e857e1e4@linux-foundation.org> (Andrew Morton's message of "Mon, 18 Apr 2022 20:42:04 -0700")

Andrew Morton <akpm@linux-foundation.org> writes:

Hi Andrew,

> On Mon, 18 Apr 2022 17:37:10 -0400 Gabriel Krisman Bertazi <krisman@collabora.com> wrote:
>
>> When provisioning containerized applications, multiple very small tmpfs
>
> "files"?

Actually, filesystems.  In cloud environments, we have several small
tmpfs associated with containerized tasks.

>> are used, for which one cannot always predict the proper file system
>> size ahead of time.  We want to be able to reliably monitor filesystems
>> for ENOSPC errors, without depending on the application being executed
>> reporting the ENOSPC after a failure.
>
> 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.

A system administrator can then use this feature to monitor a fleet of
containerized applications in a uniform way, detect provisioning issues
caused by different reasons and address the deployment.

I originally submitted this as a new fanotify event, but given the
specificity of shmem, Amir suggested the interface I'm implementing
here.  We've raised this discussion originally here:

https://lore.kernel.org/linux-mm/CACGdZYLLCqzS4VLUHvzYG=rX3SEJaG7Vbs8_Wb_iUVSvXsqkxA@mail.gmail.com/

> Whatever that action is, I see no user-facing documentation which
> guides the user info how to take advantage of this?

I can follow up with a new version with documentation, if we agree this
feature makes sense.

Thanks,

-- 
Gabriel Krisman Bertazi