From: Gabriel Krisman Bertazi <krisman@collabora.com>
To: Hugh Dickins <hughd@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Amir Goldstein <amir73il@gmail.com>
Cc: Gabriel Krisman Bertazi <krisman@collabora.com>,
kernel@collabora.com, Khazhismel Kumykov <khazhy@google.com>,
Linux MM <linux-mm@kvack.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: [PATCH RESEND 0/3] shmem: Allow userspace monitoring of tmpfs for lack of space.
Date: Mon, 4 Apr 2022 09:41:34 -0400 [thread overview]
Message-ID: <20220404134137.26284-1-krisman@collabora.com> (raw)
the only difference from v1 is addressing Amir's comment about
generating the directory in sysfs using the minor number.
* Original cover letter
When provisioning containerized applications, multiple very small tmpfs
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. 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). For this use case,
it is also interesting to differentiate IO errors caused by lack of
virtual memory from lack of FS space.
This patch exposes two counters on sysfs that log the two conditions
that are interesting to observe for container provisioning. They are
recorded per tmpfs superblock, and can be polled by a monitoring
application.
I proposed a more general approach [1] using fsnotify, but considering
the specificity of this use-case, people agreed it seems that a simpler
solution in sysfs is more than enough.
[1] https://lore.kernel.org/linux-mm/20211116220742.584975-3-krisman@collabora.com/T/#mee338d25b0e1e07cbe0861f9a5ca8cc439b3edb8
To: Hugh Dickins <hughd@google.com>
To: Andrew Morton <akpm@linux-foundation.org>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Khazhismel Kumykov <khazhy@google.com>
Cc: Linux MM <linux-mm@kvack.org>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>
Gabriel Krisman Bertazi (3):
shmem: Keep track of out-of-memory and out-of-space errors
shmem: Introduce /sys/fs/tmpfs support
shmem: Expose space and accounting error count
Documentation/ABI/testing/sysfs-fs-tmpfs | 13 +++
include/linux/shmem_fs.h | 7 ++
mm/shmem.c | 102 ++++++++++++++++++++++-
3 files changed, 120 insertions(+), 2 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-fs-tmpfs
--
2.35.1
next reply other threads:[~2022-04-04 13:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-04 13:41 Gabriel Krisman Bertazi [this message]
2022-04-04 13:41 ` [PATCH RESEND 1/3] shmem: Keep track of out-of-memory and out-of-space errors Gabriel Krisman Bertazi
2022-04-04 13:41 ` [PATCH RESEND 2/3] shmem: Introduce /sys/fs/tmpfs support Gabriel Krisman Bertazi
2022-04-04 14:02 ` Al Viro
2022-04-04 19:02 ` Gabriel Krisman Bertazi
2022-04-04 13:41 ` [PATCH RESEND 3/3] shmem: Expose space and accounting error count 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=20220404134137.26284-1-krisman@collabora.com \
--to=krisman@collabora.com \
--cc=akpm@linux-foundation.org \
--cc=amir73il@gmail.com \
--cc=hughd@google.com \
--cc=kernel@collabora.com \
--cc=khazhy@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/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).