On 03/04/2012 05:46 PM, Myklebust, Trond wrote: > On Sun, 2012-03-04 at 17:31 -0500, Steve Dickson wrote: >> >> On 03/03/2012 02:12 PM, Myklebust, Trond wrote: >>> On Sat, 2012-03-03 at 12:39 -0500, Steve Dickson wrote: >>>> >>>> On 03/02/2012 05:01 PM, Malahal Naineni wrote: >>>>> Steve Dickson [SteveD@xxxxxxxxxx] wrote: >>>>>> So what my patch does is "normalizes" the device name early >>>>>> on in main, so the correct name used used through the mount >>>>>> and when its written the mtab. Plus, for better or worses, >>>>>> since the new device name will always be shorter, I just >>>>>> reuse/rewrite the memory allocated for the argv vector.. >>>>>> Meaning there is no allocation... >>>>> >>>>> My problem is a bit different. >>>>> >>>>> "mount -t nfs4 server:export /mnt" works but umount fails. >>>>> >>>>> Notice that there is no '/' in the path! >>>>> >>>>> Normalizing or just stripping leading '/'s early won't help with the >>>>> above problem and since there is already a hack to strip the >>>>> __trailing__ '/' that kernel adds to /proc/mounts file, I just made the >>>>> existing hack it a bit better by normalizing. >>>>> >>>> How about something like this... It takes on both case early on... >>>> >>>> Author: Steve Dickson <steved@xxxxxxxxxx> >>>> Date: Sat Mar 3 12:31:23 2012 -0500 >>>> >>>> mount.nfs: Validate device name syntax >>>> >>>> To ensure the device name is found at unmount time strip >>>> off the multiple '/' or add a '/' if one does not exist. >>>> >>>> Signed-off-by: Steve Dickson <steved@xxxxxxxxxx> >>> >>> NACK. >>> >>> NFSv4 is the only protocol that has a standard mount path syntax, and >>> that is because the client performs the job of interpreting the path >>> name and translating it into PUTROOTFH followed by a bunch of LOOKUPs. >>> IOW: the standard syntax there is the one imposed by the client. >>> >>> There is nothing in the NFSv2/v3 MOUNT spec that states that a path >>> needs to start with '/'. Nor is there even anything in the spec that >>> states that '/' is required to be used as the directory component >>> separator. The X/OPEN docs state that '/' is recommended for >>> portability, but do not make it a requirement. See >>> http://pubs.opengroup.org/onlinepubs/9629799/chap8.htm#tagcjh_09_02_02_03 >>> >>> IOW: I'm perfectly allowed to set up a 'mountd' server that uses '\' or >>> even something like '|' as a path component separator. This kind of >>> patch would break the client's existing ability to mount from such a >>> server. >> And where does an server like this exist? One that uses '|' as its >> path component separator?? ;-) > > It really doesn't matter. We're supposed to be coding this sort of thing > to the spec, not to an estimate of existence. > >> Just to be clear, you are ok with striping the multiple slashes, for >> all protocol versions, but its only kosher to added the leading >> slash for v4 mounts. Correct? > > No. Please don't strip the multiple slashes either. Just leave the path > alone after you've separated it from the devicename. Well with v4 mounts the kernel code does exactly that. A mount like: mount server://///export /mnt turns into a /proc/mounts of server:/export /mnt .... which is the reason the umount can not find the mount. The same with mount server:export /mnt the /proc/mounts turns into server:/export /mnt... . which again is why the umount can not find it... > > It is quite OK to normalize the path on the _client_ side (i.e. > change //mnt to /mnt or whatever) but don't touch the server side. On the unmounts if the device name in /etc/mtab and /proc/mounts don't match then the umount fails... Again this will only happen on distro where /etc/mtab and /proc/mounts are not symbolically linked. steved. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
