There's been few reports of deadlocks in md on the lists recently, and I walked into it trying to generate flash images for my shiny new Soekris box. In particular, A previous mail mentioned something getting stuck in "wdrain": (Message-ID <[EMAIL PROTECTED]> from [EMAIL PROTECTED])
For the impatient, a way I found around the problem was to mount the md-backed filesystems with the "sync" option. I analysed the deadlock a little, and here's a synopsis, in case they're of use to anyone. This down as well as I could, and it appears to be an interaction between three processes. This may (and most likely isn't) the only md deadlock, but once I otherwise leave the backing file alone, I don't experience any problems once I mount the filesystem sync, And, because the underlying filesystem is async, access to the md filesystem isn't painfully slower than normal. 1: One thread is operating on the filesystem. In general, this thread is creating dirty buffers for later processing by the bufdaemon, and also making direct write requests. This doesn't actually participate in the deadlock, but does set the stage for it. 2: The "md" thread, processing requests from (1), attempts to lock the vnode for the underlying md device, in order to fulfill a queued write request on the md device. 3: Meanwhile.... the bufdaemon has kicked in, and is flushing dirty buffers. Some of these are for the files on the md filesystem, some are for the vnode backing the md device itself (actually, I assume that the flushing of the former causes a sudden surge in the latter, as the writes to the md filesystem are converted to writes to the backing vnode) The bufdaemon has locked the md vnode in order to write bufs to it. However, it needs to wait for "runningbufspace", which is designed to limit the number of in-flight async buffer writes. Once the running buffer space exceeds a high threshold, the scheduler is blocked, to be awakened when completed async writes bring it under the low threshold. However, a large chunk of the running buf space is sitting queued for the md thread to process. The md thread can't continue without the vnode lock, so the running buffer space will not fall, and the bufdaemon cannot continue without running buffer space, so will never release the vnode lock. -- Peter Edwards. _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"