On Tue, 2 Aug 2005, Jeff Moyer wrote: > ==> Regarding Re: [autofs] [PATCH] replicated mounts patch (local subnet > mounts now get passed addr= option); Ian Kent <[EMAIL PROTECTED]> adds: > > raven> On Mon, 1 Aug 2005, Jeff Layton wrote: > >> Hi All, Below is the latest iteration of my mount_nfs.c overhaul > >> patch. This one now passes the addr= option to the mount command when > >> the NFS server is deemed to be "local" (which in my patch is different > >> than a bind mount). > >> > >> This patch, in conjunction with the patch to mount that I sent to the > >> util-linux maintainer should give us the proper behavior when the NFS > >> server is a multihomed host and has an interface on the same subnet as > >> the client. > >> > >> I've unfortunately still not heard back from Adrian Bunk on my mount > >> patch, however, so I have no idea if that's going to go in or not. > >> > >> Still though, passing the addr= option shouldn't be harmful since the > >> current version of mount just ignores it. We just may not get the > >> desired behavior without that. > >> > >> Ian, are you still planning to consider this for inclusion in 4.1.5 or > >> 5.x? > > raven> My plan is fairly simple. > > raven> Get a basic implementation that provides direct mounts and release > raven> as first alpha. I'm likely to label it 5.0.0 as the best way to > raven> support the needed change in the protocol between the kernel and the > raven> daemon is to bump the kernel module protocol version (to 5.00 as > raven> well). > > raven> Release 4.1.5 soon after, another bug fix release to have as stable > raven> a base as possible before starting work on 4.1.6 which will include > raven> analysis and possible merge of the LDAP rework , your mount rework > raven> and the run in forground patches. > > The run in the foreground patches don't actually add any functionality. > Can we push those to v5? It seems like a pretty silly change to make in a > stable release, especially since it isn't difficult to debug autofs the way > it stands today, via logging.
I'm not to concerned myself as I also find the logging enough. So the priority on this is low. > > When you're fixing to merge in the LDAP stuff, can we get that reposted to > the list? Yep. No problem. > > raven> Following that (and probably while working on the above) I will > raven> return to working on 5.0.0. Forward porting the patches from > raven> 4.1.6. New stuff that will actually be in 5.0.0 is not final > raven> yet. There are two critical areas that still require a lot of > raven> work. First is lazy mount/umount of multi-mount mount entries. This > raven> is really difficult. Second is implementing a utility to startup and > raven> shutdown autofs to get the complexity out of the init script. > > Joy! Can I add to the list a re-write of the parser? Yes, I'll sign up to > do the leg work. This seems to be the most error-prone and fragile bit of > code. You mean the master map parser I guess. That would be the bulk of the utility I think. Fire away. > > raven> Another issue is the patch for mount that's heading for util-linux > raven> some time (and has been in the FC mount) which causes no less than 7 > raven> ports per mount to be opened. autofs opens 2 as well giving a total > raven> of 9 per mount. Only one is needed for the actual mount. As I said > raven> on the NFS list, I'm wondering if it's possible to use the SO_LINGER > raven> option to help. > > Steve Dickson fixed this. In fact, he trimmed down the number of reserved > ports used by quite a bit. Perhaps you should try out the latest rawhide > packages? Will do. But my curiosity has stired so I'm seeking an answer to how using the SO_LINGER option on a socket that has no outstanding io behaves. Ian _______________________________________________ autofs mailing list [email protected] http://linux.kernel.org/mailman/listinfo/autofs
