From owner-freebsd-geom@FreeBSD.ORG Sun Mar 22 08:13:04 2009 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 944C0106566C; Sun, 22 Mar 2009 08:13:04 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 53D8A8FC13; Sun, 22 Mar 2009 08:13:04 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 3B2C43F129; Sun, 22 Mar 2009 08:13:03 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n2M8D2xO045711; Sun, 22 Mar 2009 08:13:02 GMT (envelope-from phk@critter.freebsd.dk) To: Luigi Rizzo From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 22 Mar 2009 02:00:59 +0100." Date: Sun, 22 Mar 2009 08:13:02 +0000 Message-ID: <45710.1237709582@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: luigi@freebsd.org, Pawel Jakub Dawidek , Ivan Voras , freebsd-geom@freebsd.org Subject: Re: disk scheduling (was: Re: RFC: adding 'proxy' nodes to provider ports (with patch)) 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: Sun, 22 Mar 2009 08:13:04 -0000 In message , Luigi Rizzo writes: >The thread was meant to be on inserting transparent nodes in GEOM. > >Scheduling was just an example on where the problem came out, Scheduling is the *only* application I have seen mentioned for this special case geom construct ? >+ nobody objects that the ideal place for scheduling is where > requests naturally "pile up". Too bad that this ideal > place is sometimes one we cannot access, i.e. the firmware > of the disk drive. Do you seriously propose that we could compete in scheduling quality, with the disk drives firmware on drives that can have multiple outstanding requests ? >+ [anticipatory scheduling] > As such you can implement them effectively even above the device driver. I have yet to see any study propose that they could do any good inside the geom mesh, as opposed to right in front of the device driver ? >+ changing disksort can do some things but not all one would want. > [...] Then the correct answer is to insert a perfectly normal geom class above the disk drive to implement that. I totally fail to se what special kind of classes would buy you ? >if you want a quick example [...] I know what anticipatory disk-scheduling is, what it does, and what the downsides of it are. (I also know that with SSD's it becomes all but pointless). The question is not if we should improve disksorting, the question is if we need to hack up GEOM for it. The answer is "no". Poul-Henning -- 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.