Hmm. Well, bufdaemon is doing the right thing by blocking
in that loop. The problem appears to be related to the
double-I/O that is occuring due to the way MD filesystems
work. A vnode-backed MD takes a strategy call and turns
around and issues a high-level filesystem write. This
can deadlock the system in wdrain.
I'll take a look at it. I think the easiest thing to do
is to simply convert the async writes into synchronous
writes when we hit the I/O pipe limit, rather then
blocking.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
:I have an easy to reproduce case where my system goes into a blocking
:sleep.
:
:# mdconfig -a -t vnode -f largefile -u 0
:# newfs /dev/md0c
:# mount /dev/md0c /mnt
:# cd /mnt
:# cp -prv /boot .
:[ runs for a while and then stops ]
:
:While breaking into ddb I see that "cp", and "bufdaemon" are asleep with
:"wdrain".
:
:To my understanding, bufdaemon is the thread that takes care of flushing
:out the buffers. But as it is put to a blocking sleep, it will never get
:out of this.
:
:A quick (and dirty) fix of it is attached. It doesnt put bufdaemon to wait
:for buffers to flush. But probably this needs to be done in a different
:way. (Like not calling waitrunningbufspace() from buf_daemon())
:
:If it can be pointed out in which direction this should be solved I can
:work it out further.
:
:Thanks
:
:Mark
:
:--
:Mark Santcroos RIPE Network Coordination Centre
:http://www.ripe.net/home/mark/ New Projects Group/TTM
:
:--uQr8t48UFsdbeI+V
:Content-Type: text/plain; charset=us-ascii
:Content-Disposition: attachment; filename="vfs_bio.patch"
:
:--- vfs_bio.c.orig Thu Nov 1 08:31:30 2001
:+++ vfs_bio.c Thu Nov 1 08:30:36 2001
:@@ -270,7 +270,10 @@
: {
: while (runningbufspace > hirunningspace) {
: ++runningbufreq;
:+ if(curthread->td_proc->p_pid!=5)
: tsleep(&runningbufreq, PVM, "wdrain", 0);
:+ else
:+ break;
: }
: }
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
