mbox series

[RFC,0/2] ceph: add debugfs entries signifying new mount syntax support

Message ID 20210818060134.208546-1-vshankar@redhat.com (mailing list archive)
Headers show
Series ceph: add debugfs entries signifying new mount syntax support | expand

Message

Venky Shankar Aug. 18, 2021, 6:01 a.m. UTC
[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/dev_support
    /sys/kernel/debug/ceph/dev_support/v2
    ....
    ....

Note that there is no entry signifying v1 mount syntax. That's because
the kernel still supports mounting with old syntax and older kernels do
not have debug entries for the same.

Venky Shankar (2):
  ceph: add helpers to create/cleanup debugfs sub-directories under
    "ceph" directory
  ceph: add debugfs entries for v2 (new) mount syntax support

 fs/ceph/debugfs.c            | 28 ++++++++++++++++++++++++++++
 fs/ceph/super.c              |  3 +++
 fs/ceph/super.h              |  2 ++
 include/linux/ceph/debugfs.h |  3 +++
 net/ceph/debugfs.c           | 26 ++++++++++++++++++++++++--
 5 files changed, 60 insertions(+), 2 deletions(-)

Comments

Jeff Layton Aug. 18, 2021, 1:09 p.m. UTC | #1
On Wed, 2021-08-18 at 11:31 +0530, Venky Shankar wrote:
> [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.
> 

Is this a known bug you're talking about or are you just speculating
about the potential for bugs there?

> 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/dev_support
>     /sys/kernel/debug/ceph/dev_support/v2
>     ....
>     ....
> 
> Note that there is no entry signifying v1 mount syntax. That's because
> the kernel still supports mounting with old syntax and older kernels do
> not have debug entries for the same.
> 
> Venky Shankar (2):
>   ceph: add helpers to create/cleanup debugfs sub-directories under
>     "ceph" directory
>   ceph: add debugfs entries for v2 (new) mount syntax support
> 
>  fs/ceph/debugfs.c            | 28 ++++++++++++++++++++++++++++
>  fs/ceph/super.c              |  3 +++
>  fs/ceph/super.h              |  2 ++
>  include/linux/ceph/debugfs.h |  3 +++
>  net/ceph/debugfs.c           | 26 ++++++++++++++++++++++++--
>  5 files changed, 60 insertions(+), 2 deletions(-)
> 

I'm not a huge fan of this approach overall as it requires that you have
access to debugfs, and that's not guaranteed to be available everywhere.
If you want to add this for debugging purposes, that's fine, but I don't
think you want the mount helper to rely on this infrastructure.
Venky Shankar Aug. 18, 2021, 1:17 p.m. UTC | #2
On Wed, Aug 18, 2021 at 6:39 PM Jeff Layton <jlayton@redhat.com> wrote:
>
> On Wed, 2021-08-18 at 11:31 +0530, Venky Shankar wrote:
> > [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.
> >
>
> Is this a known bug you're talking about or are you just speculating
> about the potential for bugs there?

Potential bugs.

>
> > 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/dev_support
> >     /sys/kernel/debug/ceph/dev_support/v2
> >     ....
> >     ....
> >
> > Note that there is no entry signifying v1 mount syntax. That's because
> > the kernel still supports mounting with old syntax and older kernels do
> > not have debug entries for the same.
> >
> > Venky Shankar (2):
> >   ceph: add helpers to create/cleanup debugfs sub-directories under
> >     "ceph" directory
> >   ceph: add debugfs entries for v2 (new) mount syntax support
> >
> >  fs/ceph/debugfs.c            | 28 ++++++++++++++++++++++++++++
> >  fs/ceph/super.c              |  3 +++
> >  fs/ceph/super.h              |  2 ++
> >  include/linux/ceph/debugfs.h |  3 +++
> >  net/ceph/debugfs.c           | 26 ++++++++++++++++++++++++--
> >  5 files changed, 60 insertions(+), 2 deletions(-)
> >
>
> I'm not a huge fan of this approach overall as it requires that you have
> access to debugfs, and that's not guaranteed to be available everywhere.
> If you want to add this for debugging purposes, that's fine, but I don't
> think you want the mount helper to rely on this infrastructure.

Right. The use-case here is probably to rely on it during teuthology
tests where the mount fails (and the tests) when using the new syntax
but the kernel has v2 syntax support.

I recall the discussion on having some sort of `--no-fallback` option
to not fall-back to old syntax, but since we have the debugfs entries,
we may as well rely on those (at least for testing).

>
> --
> Jeff Layton <jlayton@redhat.com>
>
Jeff Layton Aug. 18, 2021, 1:23 p.m. UTC | #3
On Wed, 2021-08-18 at 18:47 +0530, Venky Shankar wrote:
> On Wed, Aug 18, 2021 at 6:39 PM Jeff Layton <jlayton@redhat.com> wrote:
> > 
> > On Wed, 2021-08-18 at 11:31 +0530, Venky Shankar wrote:
> > > [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.
> > > 
> > 
> > Is this a known bug you're talking about or are you just speculating
> > about the potential for bugs there?
> 
> Potential bugs.
> 
> > 
> > > 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/dev_support
> > >     /sys/kernel/debug/ceph/dev_support/v2
> > >     ....
> > >     ....
> > > 
> > > Note that there is no entry signifying v1 mount syntax. That's because
> > > the kernel still supports mounting with old syntax and older kernels do
> > > not have debug entries for the same.
> > > 
> > > Venky Shankar (2):
> > >   ceph: add helpers to create/cleanup debugfs sub-directories under
> > >     "ceph" directory
> > >   ceph: add debugfs entries for v2 (new) mount syntax support
> > > 
> > >  fs/ceph/debugfs.c            | 28 ++++++++++++++++++++++++++++
> > >  fs/ceph/super.c              |  3 +++
> > >  fs/ceph/super.h              |  2 ++
> > >  include/linux/ceph/debugfs.h |  3 +++
> > >  net/ceph/debugfs.c           | 26 ++++++++++++++++++++++++--
> > >  5 files changed, 60 insertions(+), 2 deletions(-)
> > > 
> > 
> > I'm not a huge fan of this approach overall as it requires that you have
> > access to debugfs, and that's not guaranteed to be available everywhere.
> > If you want to add this for debugging purposes, that's fine, but I don't
> > think you want the mount helper to rely on this infrastructure.
> 
> Right. The use-case here is probably to rely on it during teuthology
> tests where the mount fails (and the tests) when using the new syntax
> but the kernel has v2 syntax support.
> 
> I recall the discussion on having some sort of `--no-fallback` option
> to not fall-back to old syntax, but since we have the debugfs entries,
> we may as well rely on those (at least for testing).
> 

Ok, I think that sounds reasonable.