From: Venky Shankar <vshankar@redhat.com>
To: Jeff Layton <jlayton@redhat.com>
Cc: Patrick Donnelly <pdonnell@redhat.com>,
ceph-devel <ceph-devel@vger.kernel.org>
Subject: Re: [PATCH v2 0/2] ceph: add debugfs entries signifying new mount syntax support
Date: Thu, 26 Aug 2021 18:47:44 +0530 [thread overview]
Message-ID: <CACPzV1nNes8KxA6fVXMbZqOGaQG2qUSB0ARRfucgNRrRKtsdYw@mail.gmail.com> (raw)
In-Reply-To: <7081867582ee2fbda9da80fa1611f890f0e61372.camel@redhat.com>
On Wed, Aug 25, 2021 at 10:57 PM Jeff Layton <jlayton@redhat.com> wrote:
>
> On Wed, 2021-08-25 at 11:20 +0530, Venky Shankar wrote:
> > v2:
> > - export ceph_debugfs_dir
> > - include v1 mount support debugfs entry
> > - create debugfs entries under /<>/ceph/client_features dir
> >
> > [This is based on top of new mount syntax series]
> >
> > Patrick proposed the idea of having debugfs entries to signify if
> > kernel supports the new (v2) mount syntax. The primary use of this
> > information is to catch any bugs in the new syntax implementation.
> >
> > This would be done as follows::
> >
> > The userspace mount helper tries to mount using the new mount syntax
> > and fallsback to using old syntax if the mount using new syntax fails.
> > However, a bug in the new mount syntax implementation can silently
> > result in the mount helper switching to old syntax.
> >
> > So, the debugfs entries can be relied upon by the mount helper to
> > check if the kernel supports the new mount syntax. Cases when the
> > mount using the new syntax fails, but the kernel does support the
> > new mount syntax, the mount helper could probably log before switching
> > to the old syntax (or fail the mount altogether when run in test mode).
> >
> > Debugfs entries are as follows::
> >
> > /sys/kernel/debug/ceph/
> > ....
> > ....
> > /sys/kernel/debug/ceph/client_features
> > /sys/kernel/debug/ceph/client_features/v2_mount_syntax
> > /sys/kernel/debug/ceph/client_features/v1_mount_syntax
> > ....
> > ....
> >
>
> There are at least some scripts in teuthology that iterate over all of
> the directories under /sys/kernel/debug/ceph/. Once you add this, some
> of them may become confused.
>
> I think we might want a more generic top-level directory for this sort
> of thing, so that we only need to deal with the fallout once if we want
> to put other generic info in there.
Hmm, makes sense.
>
> Maybe something like this?
>
> /sys/kernel/debug/ceph/meta/
> /sys/kernel/debug/ceph/meta/client_features
>
> I'd be open to different names for "meta" too.
meta, misc, info, ...
I do not have a strong opinion on the naming.
>
> Also, do we really want to present this info via directories? I would
> have thought something more like a "meta/mount_syntax" file there that
> just prints "v1 v2" when read.
>
> What's easier for scripting?
One reason I kept these as files was to not do parsing stuff and just
rely on stat().
>
> > Venky Shankar (2):
> > libceph: export ceph_debugfs_dir for use in ceph.ko
> > ceph: add debugfs entries for mount syntax support
> >
> > fs/ceph/debugfs.c | 36 ++++++++++++++++++++++++++++++++++++
> > fs/ceph/super.c | 3 +++
> > fs/ceph/super.h | 2 ++
> > include/linux/ceph/debugfs.h | 2 ++
> > net/ceph/debugfs.c | 3 ++-
> > 5 files changed, 45 insertions(+), 1 deletion(-)
> >
>
> --
> Jeff Layton <jlayton@redhat.com>
>
--
Cheers,
Venky
prev parent reply other threads:[~2021-08-26 13:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-25 5:50 [PATCH v2 0/2] ceph: add debugfs entries signifying new mount syntax support Venky Shankar
2021-08-25 5:50 ` [PATCH v2 1/2] libceph: export ceph_debugfs_dir for use in ceph.ko Venky Shankar
2021-08-25 5:50 ` [PATCH v2 2/2] ceph: add debugfs entries for mount syntax support Venky Shankar
2021-09-21 14:01 ` Patrick Donnelly
2021-08-25 17:27 ` [PATCH v2 0/2] ceph: add debugfs entries signifying new " Jeff Layton
2021-08-26 13:17 ` Venky Shankar [this message]
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=CACPzV1nNes8KxA6fVXMbZqOGaQG2qUSB0ARRfucgNRrRKtsdYw@mail.gmail.com \
--to=vshankar@redhat.com \
--cc=ceph-devel@vger.kernel.org \
--cc=jlayton@redhat.com \
--cc=pdonnell@redhat.com \
/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).