Bug #19388
closed
mount.ceph does not accept -s option
Added by Michel Roelofs about 7 years ago.
Updated about 7 years ago.
Category:
Administration/Usability
Description
The mount.ceph tool does not accept the -s (sloppy) option. On Debian Jessie (and possibly more distributions), autofs adds the -s option itself. From /var/log/syslog:
Mar 26 13:17:09 access2 automount[2548]: mount_mount: mount(generic): calling mount -t ceph -s -o name=fs,secretfile=/root/cephfs.key mon001:/ /home/cephfs
Mar 26 13:17:09 access2 automount[2548]: spawn_mount: mtab link detected, passing -n to mount
Mar 26 13:17:09 access2 automount[2548]: >> Can't understand option: '-s'
Mar 26 13:17:09 access2 automount[2548]: >> usage: /sbin/mount.ceph [src] [mount-point] [-n] [-v] [-o ceph-options]
- Status changed from New to Fix Under Review
- Assignee set to Michel Roelofs
According to the release notes, autofs 5.1.1 includes a fix to avoid passing -s to filesystems other than NFS (https://lwn.net/Articles/641188/)
Is the idea here just to work around a bug for people running versions of autofs that were passing -s wrongly?
I wasn't aware of this fix in autofs, thanks for pointing me to it.
However, several mount programs accept the -s option as well. So it may be more convenient and consistent to add support for it in mount.ceph than to wait for the fixed autofs package to be deployed to all distributions. My workaround so far is to create another filesystem type in LDAP (e.g. cephautofs), so that autofs invokes /sbin/mount.cephautofs that in turn strips out the -s option.
OK, if you're motivated to do this (and update the pull request to implement -s rather than dropping it) then I don't have a problem with it.
Looking at it, it seems I'll have to update the Linux kernel as well to support the sloppy option. Doing so in a sane way would either require a significant rewrite, or I'd add it to ceph_parse_options in ceph_common.c and with that make 'sloppy' also available to rbd.
Does anybody have a preference, or an alternative idea?
The kernel client has a mount helper in src/mount/mount.ceph.c -- although that only comes into play if the ceph packages are installed on the node as well as the kernel being there. Still, if someone happened to be using the buggy autofs and a kernel cephfs moutn then they could just be told that they need the userspace mount utility.
mount.ceph passes options which it does not recognize directly to the kernel mount function, therefore a full implementation of 'sloppy' functionality cannot be done in user space alone. I now modified mount.ceph.c to pass 'sloppy' to the kernel when the '-s' commandline options is specified, and I added the 'sloppy' implementation to the net/ceph/ceph_common.c kernel code. The kernel behavior is like with nfs.
If you agree with this approach I will create two new pull requests: for the kernel and for Ceph.
Fair point about options getting passed through.
The thing I'm not sure about here is who is going to backport a fix for the kernel cephfs driver, but wouldn't backport a fix for autofs? Anyone running a very recent kernel is presumably also going to be running a sufficiently recent version of autofs that they don't have the issue anyway, so why bother adding a workaround?
Reading this thread (http://www.spinics.net/lists/autofs/msg01009.html) it seems like something that the maintainers noticed pretty quickly and addressed, so I'm unclear on what systems in the wild are really still having this problem.
My hunch is that backporting the autofs fix to debian jessie is probably going to be a simpler journey than trying to get a linux kernel patch backported, when the patch is just working around a userspace bug anyway.
Looking at the complete picture, I think it's easiest (and acceptable for me) to wait for Jessie's successor, Stretch, to be released. In Stretch RC3, autofs works properly out of the box calling /sbin/mount.ceph.
The bug may be closed.
Thanks for your feedback.
- Status changed from Fix Under Review to Closed
Also available in: Atom
PDF