Re: kernel panic + process hang with md()/ccd()/gbde

In message <20030512085711.L40541-100000_at_grogged.dyndns.org>, matt writes:

>I've been having problems of late when writing to a gbde attached ccd()
>filesystem (composed of md() devices pointed at files on a ufs1
>filesystem).

What an evil setup... :-)

You are skating along two different edges doing this:

1. md(4) with vnode backing cannot be guaranteed to avoid deadlocks.
   The reason for this is that there are some cases where one needs
   to lock all the way up to / from wherever things happen.  I
   belive that GEOM along with the consequent dedicated per md(4)
   instance thread significantly, or possibly entirely, mitigates
   this problem.  (Because it avoids sleeping in the I/O path).

   In other words, I don't think this is your problem.

2. We're not happy when people request many large buffers, and can
   get into a starvation issue.  This basically means that something
   is stuck somewhere waiting to get a big buffer, this cannot
   happen until something else releases a big buffer, but they are
   all locked until we get that big buffer we asked for.

   It's been a fair bit of time since I played with big blocksizes,
   but last I tried, I learned to avoid blocksizes larger than 16k,
   because it would simply hang my machine.

GBDE doesn't exactly help your problem here, since it also needs
temporary storage to encrypt write requests into.  (reads can be
done in-place).

I realize that DVD forces you to 32k block size, so I have not really
brought you much closer to a solution yet.

Maybe you can get away with it by slowing the copy down, or by running
"while (1) sync; sleep .5; end" in the background.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.