[autofs] Thoughts on dynamic networking with AutoFS/NFS
From: Ian Kent ra...@themaw.net On Thu, 2011-06-16 at 20:20 +0100, Colin Simpson wrote: Hi I was just wondering what the thoughts (maybe plans) are for making autofs/nfs more dynamic in the new world of dynamic networking with the likes of Network Manager now being the default. I've read this a couple of times now and I'm still not sure what to say because the mail is so open ended. But here are a few comments anyway. That might mean dbus integration which I've tried to avoid because, to me, that looks really painful and AFAICT the documentation is lousy so working out what the hell to do is difficult and frustrating. But that's not really the largest part of the work either, which I won't try and go into now, because of the main difficulty described below. We now have quite a few users with linux laptops and they want to see the standard automounts on these. But being laptops they frequently switch subnet, jump on WiFi and VPN etc. Most subsystems seem to play pretty well with this dynamic network environment and are hooked into NM (with SSSD doing a good job with off net credentials and directory services caching) Now I know that autofs/nfs is a much harder nut to crack given its heavy in kernel component, but I'd have thought the present non-dynamic behaviour is a bit of an anomaly. The issue is NFS. Dynamic fail-over for mounts has been on the NFS list of things to do for over five years and is not done yet. I'm not even sure anything is being done or has been done toward it. And that's just for the simpler case of read-only mounts. I'm not sure that is what your after either but the difficulty would be considerably more for read-write mounts. For example, although nfs mounts are stateless (nfs4 is another matter entirely), they rely on a file handle that is constructed based on server dependent information so moving from one network to another and expecting mounts to just continue to work is not going to be simple, if it is even possible. For more information on NFS plans in this area, Colin, you could post your questions to linux-...@vger.kernel.org. The NFS version 4 protocol provides lots of opportunities for client-side fail-over support, even for read/write mounts. We're working on some of these pieces now, but it will be a while. The question of NFSv3 client-side fail-over support is more sticky, as Ian has pointed out. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Thoughts on dynamic networking with AutoFS/NFS
On Mon, 2011-06-20 at 05:34 +0100, Ian Kent wrote: The problem with that is just gone can't be defined. The remove server could be rebooting and be available soon. That's true, but I wonder if it is largely machine type dependant. On a server or a workstation it may pay to wait for ever. If on a laptop it's not only unreachable but is no route to host, it's very likely gone. Maybe something that could be configurable? The lockup is usually due to NFS not being willing to discard RPC ios, as I mentioned above. The trade off is shorter wait and likely data corruption or wait! One source of the blocking is trying to umount a mount when the server is unavailable. That's actually fixable by simply not attempting to send the MOUNTPROC_UMNT to the server if it appears down. The consequence of that is showmount -d server becomes out of date since the list of client with mounts isn't updated. I'm not sure if the current umount.nfs does this. It certainly doesn't send the MOUNTPROC_UMNT at all for the lazy umount. I'm guessing one option would be to remove the mount and queue the MOUNTPROC_UMNT's somewhere? Does the server remove from this list if it hasn't heard from the client for a while? I think I'm now venturing in to the world of NFS more than autofs. I'll redraft and follow up to the NFS mailing list as suggested. Thanks again Colin This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please immediately notify the sender and delete the original. ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
[autofs] Thoughts on dynamic networking with AutoFS/NFS
Hi I was just wondering what the thoughts (maybe plans) are for making autofs/nfs more dynamic in the new world of dynamic networking with the likes of Network Manager now being the default. We now have quite a few users with linux laptops and they want to see the standard automounts on these. But being laptops they frequently switch subnet, jump on WiFi and VPN etc. Most subsystems seem to play pretty well with this dynamic network environment and are hooked into NM (with SSSD doing a good job with off net credentials and directory services caching) Now I know that autofs/nfs is a much harder nut to crack given its heavy in kernel component, but I'd have thought the present non-dynamic behaviour is a bit of an anomaly. Our present workaround is to hook a script into NM that detects when on or off lan. If going on lan to off, it will stop the autofs. If still mounts present when stopped, it will forcibly umount them. Pretty ugly, but better for the system than lots of dead mounts, which breaks lots of things (and doesn't recover if connecting to a new lan IP). Going off to on lan and starting autofs seems to recover and see the automounts fine (despite the previous brutality to the mount points we performed). We of course override the automounted home dir for the laptop owner. But they can still get to their network one via the automount when on lan. And other users can ssh into the back of these laptops (should that be necessary) and get their automounted homedir as any other machine would. Any thoughts on this (maybe the talk of integrating automounts into sssd will change things)? Or can autofs (by option maybe) be forced to clear its mounts forcibly on being stopped. I guess what I'm talking about isn't a common case but providing a consistent to office based systems for laptop users is very attractive for us. Any thoughts? Thanks Colin This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please immediately notify the sender and delete the original. ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
