From owner-freebsd-stable@FreeBSD.ORG Sat Feb 28 16:18:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE819106564A for ; Sat, 28 Feb 2009 16:18:08 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id A37B98FC0A for ; Sat, 28 Feb 2009 16:18:08 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 10BA773098; Sat, 28 Feb 2009 17:23:03 +0100 (CET) Date: Sat, 28 Feb 2009 17:23:03 +0100 From: Luigi Rizzo To: Yoshihiro Ota Message-ID: <20090228162303.GA13685@onelab2.iet.unipi.it> References: <20090228014707.6129a1bb.ota@j.email.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090228014707.6129a1bb.ota@j.email.ne.jp> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org, fabio@gandalf.sssup.it Subject: Re: Question about disk schedulers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 16:18:09 -0000 On Sat, Feb 28, 2009 at 01:47:07AM -0500, Yoshihiro Ota wrote: > Hi, Luigi and Fabio: > > I have a question about the GEOM disk scheduler you announed a while ago. > http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047597.html > > Can you tell me how does the scheduler interact with gjournal? > Do you expect to improve response time even if used together with gjounral > or to interfere each other? > > As I only had a journaled partition available for an experiment, I tried > this combination on 7.1-RELEASE but it paniced 4 times out of 5 at attempts > as soon as I mounted. Hi, a possible problem is that the scheduler uses the bio_caller1 field in the topmost request to store classification info -- there is no place to store the info in a standard 'bio' and changing the structure is rather intrusive. I see that gjournal.h has this comment: /* * Use bio_caller1 field as a pointer in queue. */ #define bio_next bio_caller1 so if gjournal is the top layer in the hierarchy there might be a conflict. Apart from adding a specific field to the struct bio (in the long term this is the way to go) perhaps one could try and add a gnop class on top of gjournal, so that would free the bio_caller1 in the topmost bio and prevent the panic. But thanks for the report, we will keep this in mind and in the next release (which should happen in a week or so) we will also add a patch or suggestion for handling this problem cheers luigi