From owner-freebsd-geom@FreeBSD.ORG Sun Mar 22 09:51:31 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 3AD54106566B; Sun, 22 Mar 2009 09:51:31 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 1E4D08FC0A; Sun, 22 Mar 2009 09:51:29 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by ewy19 with SMTP id 19so1071394ewy.43 for ; Sun, 22 Mar 2009 02:51:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=MBbSsF+IHsEMTzm6OrjBDEK7jtmvEjq3pc8IYVzYBo4=; b=uzE2dn+Bl0ytez+6j1/1IeqE6DNntjlF1GCZZk/LAbJbeGx4vk9fAM3piESK1A20Iq gmNoirKk3QEAUHj1B0cQy27wFTKeakZccYekTizRWSON9vlLOGZ1VNojHu5bRfa3L4gX chwpEYJiRQ7pZJ/jtml9dW59ZF6IVzXVLkVUY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=XSZLRaivg+yZIJkw/Eq8lA6eDX/YqeF0tPb+HNm3zT/gbuwPtrdWkIH1v5J4IWvmtc 61x41Z81stkstPlFU9J0bP9zUJTNorf0vhr19iEYZyH6jMtxfYEf7Nb0DZ0oQoXeIfmx 8Q3BjQ1J/onmKzS3tUvOExIRkPRq8AQCXyVHg= MIME-Version: 1.0 Sender: rizzo.unipi@gmail.com Received: by 10.210.19.7 with SMTP id 7mr4434008ebs.15.1237715489217; Sun, 22 Mar 2009 02:51:29 -0700 (PDT) In-Reply-To: <45710.1237709582@critter.freebsd.dk> References: <45710.1237709582@critter.freebsd.dk> Date: Sun, 22 Mar 2009 10:51:29 +0100 X-Google-Sender-Auth: fd3d421c0efbeac8 Message-ID: From: Luigi Rizzo To: Poul-Henning Kamp Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 09:51:32 -0000 On Sun, Mar 22, 2009 at 9:13 AM, Poul-Henning Kamp wrote: > 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 ? man 4 geom has a section which explicitly mentions this construct, with the same example that you posted in the thread: ... SPECIAL TOPOLOGICAL MANEUVERS INSERT/DELETE are very special operations which allow a new geom to be instantiated between a consumer and a provider attached to each other and to remove it again. To understand the utility of this, imagine a provider being mounted as a file system. Between the DEVFS geom's consumer and its provider we insert a mirror module which configures itself with one mirror copy and consequently is transparent to the I/O requests on the path. We can now configure yet a mirror copy on the mirror geom, request a synchroniza- tion, and finally drop the first mirror copy. We have now, in essence, moved a mounted file system from one disk to another while it was being used. At this point the mirror geom can be deleted from the path again; it has served its purpose. >>+ 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". Ok good, we are back on track on the geom architecture: then the question was just whether the INSERT/DELETE mentioned in the manpage was already supported or not, and how to implement it in a clean way. Hopefully the discussion in the main thread now contains enough detail to do it the right way. cheers luigi