Re: [PATCH v4 0/2] ceph: add debugfs entries signifying new mount syntax support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2021-10-19 at 10:31 +0200, Ilya Dryomov wrote:
> On Fri, Oct 1, 2021 at 7:05 AM Venky Shankar <vshankar@xxxxxxxxxx> wrote:
> > 
> > v4:
> >   - use mount_syntax_v1,.. as file names
> > 
> > [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/meta
> >     /sys/kernel/debug/ceph/meta/client_features
> >     /sys/kernel/debug/ceph/meta/client_features/mount_syntax_v2
> >     /sys/kernel/debug/ceph/meta/client_features/mount_syntax_v1
> >     ....
> >     ....
> 
> Hi Venky, Jeff,
> 
> If this is supposed to be used in the wild and not just in teuthology,
> I would be wary of going with debugfs.  debugfs isn't always available
> (it is actually compiled out in some configurations, it may or may not
> be mounted, etc).  With the new mount syntax feature it is not a big
> deal because the mount helper should do just fine without it but with
> other features we may find ourselves in a situation where the mount
> helper (or something else) just *has* to know whether the feature is
> supported or not and falling back to "no" if debugfs is not available
> is undesirable or too much work.
> 

I made this same point earlier, and the response was that this was
basically specifically for certain teuthology tests (mostly for testing
different mount syntax handling), and so debugfs should be available for
those.

> I don't have a great suggestion though.  When I needed to do this in
> the past for RADOS feature bits, I went with a read-only kernel module
> parameter [1].  They are exported via sysfs which is guaranteed to be
> available.  Perhaps we should do the same for mount_syntax -- have it
> be either 1 or 2, allowing it to be revved in the future?
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6a3408a77807037872892c2a2034180fcc08d12
> 


That's not a bad idea either, and this info _is_ read-only. I don't have
a particular preference, but this approach would be fine with me as
well, and there is already some precedent for it.
-- 
Jeff Layton <jlayton@xxxxxxxxxx>




[Index of Archives]     [CEPH Users]     [Ceph Large]     [Ceph Dev]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux