Date: Mon, 12 May 2003 22:31:58 +0200 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: matt <matt@grogged.dyndns.org> Cc: freebsd-current@freebsd.org Subject: Re: kernel panic + process hang with md()/ccd()/gbde Message-ID: <13866.1052771518@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 12 May 2003 09:24:38 CDT." <20030512085711.L40541-100000@grogged.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20030512085711.L40541-100000@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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?13866.1052771518>