On Friday June 16, aviro@redhat.com wrote:
>
>
>
> On Fri, 16 Jun 2000, Neil Brown wrote:
>
> > "base", if non-NULL, means "make sure that the returned dentry is a
> > descendant of "base".
>
> Bzzzert. Wrong. If you want that at all, at least do it right. _If_
> we want these games with the subtrees - let's create a vfsmount for each
> export and pass it as an argument. That, BTW, will solve the problem
> with umounting exported filesystems (if you don't want it - also fine, we
> can always bump the ->mnt_count on original vfsmount of export
> point).
Sorry, but I don't get this at all.
As far as I can see, filesystems need to know nothing about
mountpoints and vfsmounts and the like. They simply present trees of
directories with otherthings (files/symlinks/etc) attached at various
points. Any knowledge about how they are layered together is kept up
above in the VFS layer.
The one exception to this at present is follow_link which takes a
nameidata which contains a vfsmount.
However, from a quick scan of the source, there are precisely two
different things that filesystems do with nameidata.
1/ ignore it completely
2/ pass it to vfs_follow_link
which suggests (to me) that it probably shouldn't be passed at all -
that that is a separate thread :-).
Certainly the nfsd could create vfsmounts for the different bits of
filesystem that it deals with, but if it did, that would be for it's
own convenience. I don't see how passing a vfsmount rather than a
dentry would help the filesystem.
Maybe I should clarify how I expect this "base" to be used.
Normally the filesystem would locate the object in question and, if
it is not in the dcache already, would use some hint from the
filehandle or from the object (".." of a directory) to find the
parent and hence a name, and then attach it to the dcache.
Then it would check every parent of the object (there may be only
one) to see if the "Base" is an ancestor of that parent, and it would
only succeed if it was.
However it is possible that a filesystem might contain, in every
object, a pointer to every directory that the object is in. (I
suspect the Apollo - Domain/OS filesystem did this but I'm not
sure). If it did, then it could iterate through each pointer,
attaching the object to that part of the tree and checking if that
was a decendent of "base". Once it found a descendant it could stop.
Having presented it like that, it appears that if nfsd wanted to scan
the path from the exportpoint to object, it would need to repeat the
the iteration over parents itself, though it could only do that for
parents recorded in the dcache, while the filesystem could
potentially do it over all parents. Maybe the filesystem should
tell nfsd which parent of the found-object leads up to the "base" in
the dcache.
Hmm.. ofcourse just because the parent was a decendant of "base" when
the filesystem found it, doesn't mean that it still will be when nfsd
looks. I don't think that that causes a semantic problem for nfsd
as long as we are aware of the possibility and code defensively.
As for the unmounting-exported-filesystems, I was not aware of that. I
will explore the issue more deeply. I guess that with the possibility
of different name spaces, the interaction between mountd and nfsd needs
to be reconsidered (though there is already a problem that if you
export a directory, and then mount on top of it, mount can get
confused).
Question: would it be possible for mountd to "Attach" to the mount
table that nfsd was using, or can shareing only happen through fork/clone?
>
> > knfsd can get answers to such questions as:
> >
> > - can you support NFSD_FH_LOCATABLE
> > - is file name comparison case insensitive (will be needed for NFSv4)
>
> What case? "All world is US" strikes again...
Just reporting facts, not necessary defending them, the very latest
draft, draft 7, adds a new paragraph:
5.7. Character Case Attributes
With respect to the case_insensitive and case_preserving attributes,
each UCS-4 character (which UTF-8 encodes) has a "long descriptive
name" [RFC1345] which may or may not included the word "CAPITAL" or
"SMALL". The presence of SMALL or CAPITAL allows an NFS server to
implement unambiguous and efficient table driven mappings for case
insensitive comparisons, and non-case-preserving storage. For
general character handling and internationalization issues, see the
section "Internationalization".
NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:21 EST