Re: [PATCH] Get normalized paths for comparing NFS export paths

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

 



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.

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.

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com

��.n��������+%������w��{.n�����{��w���jg��������ݢj����G�������j:+v���w�m������w�������h�����٥



[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux