On Wed, 10 Feb 2016 18:43:38 +0000 (UTC), [email protected] (Christos Zoulas) wrote:
> John D. Baker <jdbaker%mylinuxisp.com@localhost> wrote: > > amd: pid 5064 proc c1852004 vmspace/map c19034fc flags 0 > Amd is trying to unmount a filesystem and is stuck in genfs_lock > And the million $ question is: > Is amd trying to unmount because of the shutdown, or because of the > periodic mount timeout? If the second, do we have a locking race during > unmount? It was in this state for a while (several hours) before I tried to shut down... > Unfortunately looks like you'll have to reboot and redo the test to > answer this. To make it unambiguous, I'll definitely arrange to do this again. One thing that might shed light on the situation. My experience has been that running 'cvs update' blocks just about all other access to a file system until it's complete. The machines on which I build releases have the file system "hard" NFS mounted (not via 'amd') and even they stall accessing while 'cvs update' is running on the file server. If such a machine is also using an 'amd'-managed mount and is running 'firefox', even the "hard" NFS mount will eventually hang. In case it's relevant, the file server exports its big file system with "-alldirs", so clients can mount at any point that is appropriate for their use. I use things like: /r0/home User home directories /r0/nbsd NetBSD src/xsrc/pkgsrc trees /r0/diskless/foo Root directory for diskless client "foo" and so forth. Clients "hard"-mount "/r0/nbsd" (and their NFS root, etc. if diskless) but access "/r0/home" via 'amd' w/custom "/home" map, or any arbitrary subdirectory via the 'amd' "/net" map. Until recently, it never outrigh hung--just the delays that occurred when running 'cvs update' on the file server. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]mylinuxisp[flyspeck]com OpenBSD FreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
