From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 06:45:25 2005 Return-Path: X-Original-To: current@freebsd.org 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 DB8E916A41C; Fri, 15 Jul 2005 06:45:25 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40D2343D49; Fri, 15 Jul 2005 06:45:22 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j6F6oNd7081946; Fri, 15 Jul 2005 00:50:23 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42D75B84.7090601@samsco.org> Date: Fri, 15 Jul 2005 00:45:24 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Poul-Henning Kamp References: <8462.1121409797@phk.freebsd.dk> In-Reply-To: <8462.1121409797@phk.freebsd.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: Luigi Rizzo , s223560@studenti.ing.unipi.it, Robert Watson , current@freebsd.org Subject: Re: location of bioq lock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Fri, 15 Jul 2005 06:45:26 -0000 Poul-Henning Kamp wrote: > In message <20050714181356.A58300@xorpc.icir.org>, Luigi Rizzo writes: > > >>Anyways there might be a way out... >>requests go from dev_strategy() > > > The right place for this is geom_disk.c:g_disk_start() and the start > routines of the drivers which do not use geom_disk. > > The easiest way to handle it would be to set a flag on the g_provider > saying "no more", have g_down spill the requests into a side queue > and when the driver is ready again, it calls some function which > pulls the request out of the side queue again. > > I agree. The 'side queue' can be a bioq also that gets handed off in whole to the driver once the path is unfrozen, but that's an optimization that is best done at a later time. Scott