Ollivier Robert wrote:
> According to Kris Kennaway:
> > load: 0.00 cmd: tcsh 8403 [inode] 0.01u 0.00s 0% 1076k
>
> The dreaded "inode" problem. I've been seeing this from time to time where the
> system will be blocked for all I/O on a given disk with all processes waiting
> on "inode".
>
> Generally updating the system to a more recent "fixes" the problem till next
> time. I don't know where it comes from :-(
It's actually the name for "vp->v_vnlock" from FFS; specifically,
line #1231 of /usr/src/sys/ufs/ffs/ffs_vfsops.c. It's actually the
address of the vp->v_lock.
Acquisition supposedly times out in 50ms.
You may want to try compiling with:
options DEBUG_LOCKS
It's locked and unlocked in /usr/src/sys/kern/vfs_default.c in
vop_stdlock(), vop_stdunlock() (which should also be instrumented
for DEBUG_LOCKS, but isn't), vop_sharedlock(), and (sort of) in
vop_nolock().
So try the option, if that doesn't work, instrument vop_stdlock()
and try it again, and if that still gives no information, check
with whoever wrote the code.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
