Re: cvs commit: src/sys/ufs/ffs ffs_softdep.c softdep.h

Peter Jeremy writes:
| On Thu, 2005-Aug-11 22:54:35 -0700, Doug Ambrisko wrote:
| >Alexandr Kovalenko writes:
| >| Could this be the fix for the problem when unpacking large archives on
| >| soft-updates-enabled volumes? (I experience complete lockup of
| >| filesystem operations at some point of time during extracting files, for
| >| example - cd /usr/ports/editors/openoffice-1.1 && make extract)
| >
| >Don't think so.  Different bug that I found:
| 
| ...
| >+			if (curthread->td_proc == bufdaemonproc)
| >+				panic("Buffer Daemon lockup %s\n", waitmsg);
| 
| >Please try this patch and let me know if it helps.  Watch for:
| >	buf daemon has some potential space
| >in dmesg etc.  I haven't tested this version much in -current but
| >the same basic code saves our 4.X systems.
| 
| Patches don't work for me on -current from about 1400UT on Thursday.
| 
| I was trying to move /usr to a new disk with:
| # mount -o async /dev/ad3s3d /mnt
| # cd /mnt
| # dump -0a -C 16 -f - /usr | restore -rf -
| and it panic'd when the restore was creating the directory hierarchy.
| (/usr has ~150K inodes, not sure how many directories - there's one
| src tree but ports, obj and ncvs are elsewhere).
| 
| Messages were:
| buf daemon has some potential space 622592
| panic: Buffer Daemon lockup newbuf
| KDB: stack backtrace:
| kdb_backtrace(c06d62f9,c073a740,c06dda45,d570ba30,100) at kdb_backtrace+0x2e
| panic(c06dda45,c06dd435,c06dd4ea,765,c06d5222) at panic+0xb7
| getnewbuf(0,0,1800,4000,cbea2958) at getnewbuf+0x6d0
| geteblk(1800,0,c06e6fb2,643,cbea29b8) at geteblk+0x3a
| ffs_bufwrite(cbea2958,c059d94a,c070d360,246,c0714024) at ffs_bufwrite+0x1de
| vfs_bio_awrite(cbea2958,0,c06dd4ea,845,0) at vfs_bio_awrite+0x29e
| flushbufqueues(0,0,c06dd4ea,7bf,3e8) at flushbufqueues+0x47d
| buf_daemon(0,d570bd38,c06d34ac,30d,0) at buf_daemon+0xd4
| fork_exit(c057f4f0,0,d570bd38) at fork_exit+0xc1
| fork_trampoline() at fork_trampoline+0x8
| 
| I have a crashdump and it looks like kgdb can make some sense out of it.
| /mnt was mounted async but I'd also had a panic when it was mounted with
| soft-updates (though the system rebooted before I got details).
| 
| BTW, this system _didn't_ have any problem untarring or building OpenOffice
| (though that was into a different filesystem).  Let me know if there's
| any more details you'd like.

Thanks for the feed back.  I'll take a look to see how things have changed
which might have caused some problems.  Can you send me the patched
file?  Not the new patch but the entire file.  Then I might have some
things for you to do against that core.  I'll also try to repro. it on
-current.

Doug A.