In Message <Pine.NEB.4.51.0302021501110.264@hammer.hhhh.org> ,
   Konrad Schroder <perseant@hhhh.org> wrote:

=>On Sun, 2 Feb 2003, Gary Duzan wrote:
=>
=>> #13 0xc01c18cb in lfs_remove (v=0xe411bcbc)
=>>     at /usr/src/sys/ufs/lfs/lfs_vnops.c:632
=>> #14 0xc01c6da8 in ufs_rename (v=0xe411be70) at /usr/src/sys/sys/vnode_if.h:686
=>> #15 0xc01c1f0f in lfs_rename (v=0xe411be70)
=>>     at /usr/src/sys/ufs/lfs/lfs_vnops.c:741
=>[...]
=>>    Any ideas about what is going on here? I have a good core dump,
=>> and I can reliably recreate the problem, so suggestions on things
=>> to check and/or try would be appreciated.
=>
=>I think you should be able to duplicate this condition by something like
=>
=>	cd /my/lfs
=>	: > foo
=>	ln foo bar
=>	mv foo bar
=>
=>at least, that should duplicate your stack trace.

   It did duplicate the condition.

=>                                                   The problem that causes
=>this assertion failure is that lfs_remove is being called while the
=>original dirop (lfs_rename) is still active on the same inode.

   I knew that looked screwy...

=>                                                                I've just
=>committed the obvious fix for that, although it's not immediately clear
=>that this double-dirop is the cause of your original problem.

   Well, it fixed the immediate problem, anyway. The above example
is fixed and the build completes normally. I haven't worked out
all the details, but I think it fixes the original problem, too,
since we've eliminated the bogus call path, ufs_rename -> lfs_remove
-> lfs_set_dirop -> lfs_reserve -> lfs_reservebuf, which updates
the counter. I didn't see the lfs_fits_buf warning during the build,
either, so I think we can call it fixed for now.
   Thanks.

					Gary Duzan