On Mon, 10 Feb 2014 23:19:09 -0500 Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx> wrote: > > On Feb 10, 2014, at 21:30, NeilBrown <neilb@xxxxxxx> wrote: > > > > > (I seem to have quite a pile of NFS issues lately.... some if it is tidying up > > issues from before Christmas, some of it just keeps on coming :-) > > > > If you run "mount -a" it will attempt to mount all filesystems listed > > in /etc/fstab, but filesystems that are already mounted will not be mounted > > again. So it is normally safe to run "mount -a" multiple times. > > > > However if an NFS mount in /etc/fstab has the "nosharecache" option set, > > mount doesn't notice that it is already mounted as so mounts it again. So > > repeated "mount -a" is no longer safe. > > > > This happens because the prevention of multiple mounts happens in do_add_mount > > in fs/namespace.c: > > > > err = -EBUSY; > > if (path->mnt->mnt_sb == newmnt->mnt.mnt_sb && > > path->mnt->mnt_root == path->dentry) > > goto unlock; > > > > > > i.e. if the exact same superblock is being mounted in the exact same place, > > return EBUSY. > > With nosharecache, every mount attempt produces a new superblock so this test > > never fires. > > > > One way to address this would be to have a different option, e.g. > > sharecache=27 > > > > where the '27' is an arbitrary number meaning that if two mount attempts have > > different sharecache numbers they will have different superblocks. If they > > have the same sharecache number they can have the same superblock. > > This is not the most elegant interface ever and I would be very happy for > > suggestions to improve it. Maybe a string rather than a number ??? > > > > This probably isn't a very serious issue, but is a regression in terms of the > > usability of "mount -a" and I think it would be best to fix it if the cost is > > not too high. > > > > Below is my patch to implement the "sharecache=%u" syntax. > > > > Any ideas? > > What are people using nosharecache for these days, and why is this not another argument for just getting rid of it? Baby or bath water? In the particular case that brought this up for me they are actually using "nosharetransport" which is a similar option I provide in SLES because there are cases where sharing the transport reduces performance, and cases where sharing the transport interacts poorly with particular details (of particular versions) of the Netapp filer. Seeing the root problem is the same for nosharecache and nosharetransport it seems reasonable to report it upstream as an issue with nosharecache. If you don't think this is worth "fixing", I certainly don't feel strongly enough about it to argue. Thanks, NeilBrown
Attachment:
signature.asc
Description: PGP signature
