[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: "device busy" reading file from NFS
In article <20090426192311.GB15148%hairylemon.org@localhost>,
Andrew Doran <ad%netbsd.org@localhost> wrote:
>On Sun, Apr 26, 2009 at 08:19:24AM -0500, John D. Baker wrote:
>> I've been having problems with 5.0_RCx NFS clients (i386) on my 4.0_STABLE
>> NFS servers (sparc64 and i386). I use 'amd' to automount a lot of
>> things. Mostly, I'm rebuilding the system with sources on NFS and all
>> other directories on local disk.
>> The process will run fine until an attempt to read some file causes
>> the (usually compiler) to stop, with a complaint similar to:
>> In file included from
>> /amd/kob/r0/nbsd/netbsd-5/src/dist/ntp/include/ntp.h:17:22: error:
>> Device busy
>> Has anyone else seen something similar?
>From the PR:
> I'm guessing how amd works - haven't researched it yet - but I think the
> main problem will be new calls to VFS_ROOT() from lookup(). While an idle
> file system is being garbage collected by amd, those will fail with EBUSY.
> So there's a small window across the unmount where operations would fail
> instead of causing an automount to occur.
> For an unmount that's not forced, those should be easy enough to gate
> because it's OK to wait there. The deadlocks (some of which have been there
> for a long time) start happening when we cause threads already in the guts
> of the file system code to wait, because there is a tangled mess of locks.
>Code hasn't been written to deal with this properly yet. I didn't envision
>that it would fire with any regularity and we haven't had any problem
>reports up until this week. :-(. I will see about fixing it, but it will not
>be in time for 5.0.
Can you try to add retry=3 to the mount options in the maps. This is clearly
Main Index |
Thread Index |