On Wed, 2006-05-24 at 10:04 -0400, Peter Staubach wrote: > 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! It's in autofs 5 now. The idea is that it will work for any mount string, replicated syntax or not. So there's no extra mucking around. I hope to push it into mount and provide a configure option to disable it in autofs if mount can do it instead. > > >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. Yep. > > > >> 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. Any and all information is good. Food for thought will give me something to eat! Ian - 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
