From owner-freebsd-geom@FreeBSD.ORG Tue Jul 25 13:26:59 2006 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BEDEB16A4DD for ; Tue, 25 Jul 2006 13:26:59 +0000 (UTC) (envelope-from arne_woerner@yahoo.com) Received: from web30313.mail.mud.yahoo.com (web30313.mail.mud.yahoo.com [68.142.201.231]) by mx1.FreeBSD.org (Postfix) with SMTP id 512FA43D45 for ; Tue, 25 Jul 2006 13:26:59 +0000 (GMT) (envelope-from arne_woerner@yahoo.com) Received: (qmail 35259 invoked by uid 60001); 25 Jul 2006 13:26:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=b8KdgLh0OnVlg38RLerBi+2M+ShR2QZ5NIGYV+v9yy+FyPS+fhR7Ognl3kYI7OS8lv+c56vwtGjvffLOoh1MCetDtmBRRJ9Mew3nRxcExIjdZU/u7SLpVgGdT2Ox6PvpGWlCXvsvD4WmEk1sxFqKv8Y3L+CGkc3GB+u72JZyxtk= ; Message-ID: <20060725132658.35256.qmail@web30313.mail.mud.yahoo.com> Received: from [213.54.65.59] by web30313.mail.mud.yahoo.com via HTTP; Tue, 25 Jul 2006 06:26:58 PDT Date: Tue, 25 Jul 2006 06:26:58 -0700 (PDT) From: "R. B. Riddick" To: freebsd-geom@freebsd.org In-Reply-To: <20060714122936.17967.qmail@web30302.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: new class / geom_raid5 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2006 13:26:59 -0000 --- "R. B. Riddick" wrote: > I solved the deadlock by pretending a lack of memory, so that the request, > that > was to be ->start()'ed is pushed back to the end of the down queue, which > slows > down all requests of every geom (due to pace) a little bit, doesn't it? > Now I put those write requests, that might be in violation of consistency rules, into an own queue, that is flushed, when the conflicting synchronization cycle is over... So now we do not have that artificial delay problem due to the ENOMEM trick... I hope, my assumption that the write requests are executed in the order they are g_io_request'ed, is right... Or isn't it? Is it necessary to wait for the call to ...done() before I order a conflicting g_io_request()? E. g.: If we had a write request A to a dirty area immediately before it is synchronized: Can we be sure, that the synchro-reads already find the data out of request A? Has somebody done some graid5-tests in the meantime? Am I doing something wrong? I mean: Regarding the etiquette of this list or so... -Arne __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com