| Message ID | 20210825055035.306043-1-vshankar@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | ceph: add debugfs entries signifying new mount syntax support | expand |
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. 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. 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? > 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(-) >
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> >
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 .... .... 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(-)