Ian Kent wrote:
Of course, like #1 but with the benefits of #2 without the clutter. I
guess all I would have to do then is the vfs mount to make it happen.
Are we assuming a restriction like all the mounts have the same path
exported from the server? mtab could get a little confused.
I don't think that this needs to be restricted like this. I think that
it would be nice if mtab just showed the arguments which were used to
the mount command, ie. with all of the server and path combinations listed
just like they were on the command line or in the autofs map.
But I'm not supposed to peek at that am I (cough, splutter, ...)?
Yes, I know. I am trying to figure out how much of the architecture and
implementation that I can talk about too... :-)
Cool. That's the way the selection code I have works, except for the
kernel bit of course.
Good news!
Yep. Failing over the locks looks like it could turn into a nightmare
really fast. Sounds like a good simplifying restriction for a first stab
at this.
Agreed.
Interesting. This hadn't occurred to me yet.
I was still at the stage of wondering whether the "on demand" approach
would work but the simplifying restriction above should make it workable
(I think ....).
I think that simple is good. We can always get more complicate later, if
need be. (Hope not... :-) )
The key ingredient to this approach, I think, is a list of servers and
information about them, and then information for each active NFS inode
that keeps track of the pathname used to discover the file handle and
also the server which is being currently used by the specific file.
Haven't quite got to the path issues yet.
But can't we just get the path from d_path?
It will return the path from a given dentry to the root of the mount, if
I remember correctly, and we have a file handle for the server.
But your talking about the difficulty of the housekeeping overall I
think.
Yes, I was specifically trying to avoid talking about how to manage the
information. I think that that is an implementation detail, which is
better left until after the high level architecture is defined.
Thanx...
Thanks for your comments.
Much appreciated and certainly very helpful.
You're welcome.
I can try to talk more about the architecture and implementation that I am
familiar with, if you like.
ps
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
