From owner-freebsd-current@FreeBSD.ORG Mon May 12 13:32:00 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB9EE37B401 for ; Mon, 12 May 2003 13:32:00 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6B9743F85 for ; Mon, 12 May 2003 13:31:59 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h4CKVwYP013867; Mon, 12 May 2003 22:31:58 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: matt From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 12 May 2003 09:24:38 CDT." <20030512085711.L40541-100000@grogged.dyndns.org> Date: Mon, 12 May 2003 22:31:58 +0200 Message-ID: <13866.1052771518@critter.freebsd.dk> cc: freebsd-current@freebsd.org Subject: Re: kernel panic + process hang with md()/ccd()/gbde X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2003 20:32:00 -0000 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.