From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Kent Subject: Re: Re: [RFC] Multiple server selection and replicated mount failover Date: Wed, 24 May 2006 22:31:35 +0800 Message-ID: <1148481095.8182.29.camel@raven.themaw.net> References: <44745972.2010305@redhat.com> <1148478346.8182.22.camel@raven.themaw.net> <44746803.9000909@redhat.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: nfs@lists.sourceforge.net, linux-fsdevel , autofs mailing list Return-path: To: Peter Staubach In-Reply-To: <44746803.9000909@redhat.com> Sender: nfs-admin@lists.sourceforge.net Errors-To: nfs-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: List-Id: linux-fsdevel.vger.kernel.org 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 ------------------------------------------------------- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs