From: Jeff Layton <jlayton@kernel.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
Ian Kent <raven@themaw.net>, Josef Bacik <josef@toxicpanda.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 0/3] fs: allow statmount to fetch the fs_subtype and sb_source
Date: Tue, 12 Nov 2024 06:12:32 -0500 [thread overview]
Message-ID: <aca5eab83da33e2accb16af45c36762671fc900c.camel@kernel.org> (raw)
In-Reply-To: <CAJfpegtPY+g5nApZ47AGbexncJrvUJ7iCotYpgApCHzGDONGqg@mail.gmail.com>
On Tue, 2024-11-12 at 11:32 +0100, Miklos Szeredi wrote:
> On Mon, 11 Nov 2024 at 16:10, Jeff Layton <jlayton@kernel.org> wrote:
> >
> > Meta has some internal logging that scrapes /proc/self/mountinfo today.
> > I'd like to convert it to use listmount()/statmount(), so we can do a
> > better job of monitoring with containers. We're missing some fields
> > though. This patchset adds them.
> >
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
>
> When thinking of the naming for the unescaped options, I realized that
> maybe "source" is better than "sb_soure" which just adds redundant
> info. Just a thought, don't bother if you don't agree.
>
> Acked-by: Miklos Szeredi <mszeredi@redhat.com>
>
I think sb_source fits better with the convention that the other fields
in the struct use. I say we stick with that.
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2024-11-12 11:12 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-11 15:09 Jeff Layton
2024-11-11 15:09 ` [PATCH v4 1/3] fs: don't let statmount return empty strings Jeff Layton
2024-11-11 17:44 ` Jan Kara
2024-11-11 15:09 ` [PATCH v4 2/3] fs: add the ability for statmount() to report the fs_subtype Jeff Layton
2024-11-11 15:09 ` [PATCH v4 3/3] fs: add the ability for statmount() to report the sb_source Jeff Layton
2024-11-12 10:32 ` [PATCH v4 0/3] fs: allow statmount to fetch the fs_subtype and sb_source Miklos Szeredi
2024-11-12 11:12 ` Jeff Layton [this message]
2024-11-12 13:39 ` Christian Brauner
2024-11-13 11:27 ` Karel Zak
2024-11-13 13:08 ` Miklos Szeredi
2024-11-13 13:45 ` Jeff Layton
2024-11-13 15:18 ` Jan Kara
2024-11-13 15:49 ` Miklos Szeredi
2024-11-13 16:00 ` Jan Kara
2024-11-14 1:45 ` Ian Kent
2024-11-14 11:56 ` Jan Kara
2024-11-14 13:20 ` Miklos Szeredi
2024-11-17 23:29 ` Ian Kent
2024-11-18 9:07 ` Jan Kara
2024-11-14 1:51 ` Ian Kent
2024-11-14 11:29 ` Christian Brauner
2024-11-14 12:29 ` Jeff Layton
2024-11-14 13:16 ` Miklos Szeredi
2024-11-14 14:48 ` Christian Brauner
2024-11-14 14:51 ` Jeff Layton
2024-11-14 15:09 ` Christian Brauner
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=aca5eab83da33e2accb16af45c36762671fc900c.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=brauner@kernel.org \
--cc=jack@suse.cz \
--cc=josef@toxicpanda.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=raven@themaw.net \
--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
all inboxes | Powered by JetHome®