From: Andrew Morton <akpm@linux-foundation.org>
To: Gabriel Krisman Bertazi <krisman@collabora.com>
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: Mon, 18 Apr 2022 20:42:04 -0700 [thread overview]
Message-ID: <20220418204204.0405eda0c506fd29e857e1e4@linux-foundation.org> (raw)
In-Reply-To: <20220418213713.273050-1-krisman@collabora.com>
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"?
> 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.
> It is also not enough to watch
> statfs since that information might be ephemeral (say the application
> recovers by deleting data, the issue can get lost).
We could fix the apps? Heck, you could patch libc's write() to the same
effect.
> For this use case,
> it is also interesting to differentiate IO errors caused by lack of
> virtual memory from lack of FS space.
More details, please. Why interesting? What actions can the system
operator take based upon this information?
Whatever that action is, I see no user-facing documentation which
guides the user info how to take advantage of this?
next prev parent reply other threads:[~2022-04-19 3:42 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-18 21:37 [PATCH v3 0/3] shmem: Allow userspace monitoring of tmpfs for lack of space Gabriel Krisman Bertazi
2022-04-18 21:37 ` [PATCH v3 1/3] shmem: Keep track of out-of-memory and out-of-space errors Gabriel Krisman Bertazi
2022-04-18 21:37 ` [PATCH v3 2/3] shmem: Introduce /sys/fs/tmpfs support Gabriel Krisman Bertazi
2022-04-22 9:54 ` Dan Carpenter
2022-04-18 21:37 ` [PATCH v3 3/3] shmem: Expose space and accounting error count Gabriel Krisman Bertazi
2022-04-19 3:42 ` Andrew Morton [this message]
2022-04-19 15:28 ` [PATCH v3 0/3] shmem: Allow userspace monitoring of tmpfs for lack of space Gabriel Krisman Bertazi
2022-04-21 5:33 ` Amir Goldstein
2022-04-21 22:37 ` Gabriel Krisman Bertazi
2022-04-21 23:19 ` Khazhy Kumykov
2022-04-22 9:02 ` Amir Goldstein
2022-05-05 21:16 ` Gabriel Krisman Bertazi
2022-05-12 20:00 ` Gabriel Krisman Bertazi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220418204204.0405eda0c506fd29e857e1e4@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=amir73il@gmail.com \
--cc=hughd@google.com \
--cc=kernel@collabora.com \
--cc=khazhy@google.com \
--cc=krisman@collabora.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).