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

[moved to -current]
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.

-- 
Peter Jeremy