Messages in this thread | | | Date | Thu, 3 Feb 2000 00:09:08 +0100 | From | Frank van Maarseveen <> | Subject | Re: autofs 4.0.0 (pre1) |
| |
On Thu, Jan 27, 2000 at 12:20:49AM -0800, Jeremy Fitzhardinge wrote: > >> What version are you comparing it to? > > 2.2.10-ac11 > > > > In case you're wondering why: almost no 2.2.x kernel is usable (at my > > work) because they all suffer from an NFS client bug which is fixed by > > Trond's patch I'm using in 2.2.13. Without this patch, redirecting setuid > > program output to an NFS mounted FS fails: data is discarded because I/O > > is done with the credentials of the calling process (e.g. setuid root) > > instead of the opener of the file. > > Well, my patches do nothing to the behaviour of NFS. Are you saying that > autofs 4 is more stable than a previous version of autofs with 2.2.x? Yes.
2.2.10-ac11 autofs didn't panic/oops the system but gave some troubles when a (non-Linux) server disk was resized or was temporarily offline. I don't recall the details but at times it was difficult to get rid of old mounts and/or to restart autofs. It had all to do with error handling (or maybe also a race) during mount/umount actions.
First impression is that the new autofs together with a new mount behaves better. I still have to test it more systematically but I'll use this new autofs anyway. We'll see what happens.
One concern is that all automounts here are hard NFS mounts: except for a stall server/network problems should never disrupt operations on NFS clients. On the other hand, when a server disk has been resized every NFS operation on old mounts will yield ESTALE. Mount expiration and even restarting autofs should still work in this case and not block on the error.
Another concern is the mount program which must try forever and not timeout when the server is not responding at mount time. I think mount expiration should block as well in this case except when forced by an autofs stop/restart.
-- Frank
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |