From owner-freebsd-geom@FreeBSD.ORG Mon Mar 16 11:06:55 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 096671065687 for ; Mon, 16 Mar 2009 11:06:55 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EAD1C8FC14 for ; Mon, 16 Mar 2009 11:06:54 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n2GB6sGZ043242 for ; Mon, 16 Mar 2009 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n2GB6sGV043238 for freebsd-geom@FreeBSD.org; Mon, 16 Mar 2009 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 16 Mar 2009 11:06:54 GMT Message-Id: <200903161106.n2GB6sGV043238@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-geom@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org 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: Mon, 16 Mar 2009 11:06:55 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/132273 geom [glabel] [patch] failing on journaled partition o kern/132242 geom [gmirror] gmirror.ko fails to fully initialize o kern/131575 geom [geom_label] [msdosfs] [umass] Immediate crash after p o kern/131353 geom [geom] gjournal(8) kernel lock o kern/131037 geom [geli] Unable to create disklabel on .eli-Device o kern/130528 geom gjournal fsck during boot o kern/129674 geom [geom] gjournal root did not mount on boot o kern/129645 geom gjournal(8): GEOM_JOURNAL causes system to fail to boo o kern/129245 geom [geom] gcache is more suitable for suffix based provid o bin/128398 geom [patch] glabel(8): teach geom_label to recognise gpt l f kern/128276 geom [gmirror] machine lock up when gmirror module is used o kern/126902 geom [geom] [geom_label] Kernel panic during install boot o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s o kern/124294 geom [geom] gmirror(8) have inappropriate logic when workin o kern/124130 geom [gmirror] [usb] gmirror fails to start usb devices tha o kern/123962 geom [panic] [gjournal] gjournal (455Gb data, 8Gb journal), o kern/123630 geom [patch] [gmirror] gmirror doesnt allow the original dr o kern/123122 geom [geom] GEOM / gjournal kernel lock f kern/122415 geom [geom] UFS labels are being constantly created and rem o kern/122067 geom [geom] [panic] Geom crashed during boot o kern/121559 geom [patch] [geom] geom label class allows to create inacc o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/120231 geom [geom] GEOM_CONCAT error adding second drive o kern/120044 geom [msdosfs] [geom] incorrect MSDOSFS label fries adminis o kern/120021 geom [geom] [panic] net-p2p/qbittorrent crashes system when o kern/119743 geom [geom] geom label for cds is keeped after dismount and f kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile o kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113419 geom [geom] geom fox multipathing not failing back p bin/110705 geom gmirror(8) control utility does not exit with correct o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to o kern/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML o kern/98034 geom [geom] dereference of NULL pointer in acd_geom_detach o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o bin/90093 geom fdisk(8) incapable of altering in-core geometry a kern/89660 geom [vinum] [patch] [panic] due to g_malloc returning null o kern/89546 geom [geom] GEOM error s kern/89102 geom [geom] [panic] panic when forced unmount FS from unplu o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o kern/84556 geom [geom] [panic] GBDE-encrypted swap causes panic at shu o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o bin/78131 geom gbde(8) "destroy" not working. s kern/73177 geom kldload geom_* causes panic due to memory exhaustion 48 problems total. From owner-freebsd-geom@FreeBSD.ORG Mon Mar 16 16:57:58 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 F00D21065670; Mon, 16 Mar 2009 16:57:58 +0000 (UTC) (envelope-from lulf@FreeBSD.org) Received: from bene1.itea.ntnu.no (bene1.itea.ntnu.no [IPv6:2001:700:300:3::56]) by mx1.freebsd.org (Postfix) with ESMTP id D87308FC21; Mon, 16 Mar 2009 16:57:57 +0000 (UTC) (envelope-from lulf@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by bene1.itea.ntnu.no (Postfix) with ESMTP id 20C1F16C73E; Mon, 16 Mar 2009 17:57:56 +0100 (CET) Received: from carrot (unknown [IPv6:2001:700:300:3::184]) by bene1.itea.ntnu.no (Postfix) with ESMTP id 6273D16C3A2; Mon, 16 Mar 2009 17:57:55 +0100 (CET) Date: Mon, 16 Mar 2009 16:58:00 +0100 From: Ulf Lilleengen To: freebsd-current@freebsd.org Message-ID: <20090316155800.GA2257@carrot> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) X-Virus-Scanned: Debian amavisd-new at bene1.itea.ntnu.no Cc: freebsd-arch@freebsd.org, freebsd-geom@freebsd.org Subject: [HEADS UP] Merge of projects/gvinum to head 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: Mon, 16 Mar 2009 16:58:00 -0000 --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, This is a heads-up for a merge of gvinum project code into HEAD. This means that gvinum implementation will be changed some. The code is based on the work done by Lukas Ertl as well as the work I did before/during Google SoC 2007 and afterwards. It has been staying in p4 for some time, and then moved to the subversion project repository not long ago. The main reason for the delay of getting this into HEAD have been the lack of reviewers of the code, but after some discussion and help from testers, I've decided this is a good time to get it in (should perhaps have been merged a bit earlier) Testers have spotted several differences from the original gvinum, and I've tried to make it behave as the old implementation wherever that seemed the best way = to go. Luckily, the work has gotten a bit of attention lately, thanks to Rick = C. Petty for helping out with testing and bugfixing, as well as all others who have dared to run the new gvinum. So, what does this update offer? =46rom the user aspect: - Implementation of many of the missing commands from the old vinum: attach/detach, start (was partially implemented), stop (was partially implemented), concat, mirror, stripe, raid5 (shortcuts for creating volum= es with one plex of these organizations). - Support for fixing degraded plexes while mounted. - Support for growing for striped and raid5-plexes, meaning that one can extend the volumes for these plex types in addition to the concat type. Also works while the volume is mounted. - The parity check and rebuild no longer goes between userland/kernel, meaning that your gvinum command will not stay and wait forever for the rebuild to finish. You can instead watch the status with the list command. - Many problems with gvinum have been reported since 5.x, and some has been hard to fix due to the complicated architecture. Hopefully, it should be more stable and better handle edge cases that previously made gvinum crash. - Failed drives no longer disappears entirely, but now leave behind a dummy drive that makes sure the original state is not forgotten in case the system is rebooted between drive failures/swaps. =46rom the technical aspect: - Gvinum now uses one single workerthread instead of one thread for each volume and each plex. The reason for this is that the previous scheme was very complex, and was the cause of many of the bugs discovered in gvinum. Instead, gvinum now uses one worker thread with an event queue, quite similar to what used in gmirror. - The rebuild/grow/initialize/parity check routines no longer runs in separate threads, but are run as regular I/O requests with special flags. This made it easier to support on-mount growing and parity rebuild. Probably, there are many other issues that have been fixed, perhaps new issues introduced. This is why this is dropped in HEAD now, to give it more attention from the uses before the 8.0 branch. All in all, this will make gvinum an easier beast to handle for users. If you have any issues related = to this, send in problem reports or drop me an e-mail, and I'll take a look. For interested reviewers, the code resides in svn://svn.freebsd.org/base/projects/gvinum --=20 Ulf Lilleengen --KsGdsel6WgEHnImy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkm+dwAACgkQCILg8nMIdCV7TwCfYyxEvLTHgZqcscpXqPdldHIK 81EAnj4lc0hUj/O78iMd3gFEgs6rmRe+ =BAnc -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy-- From owner-freebsd-geom@FreeBSD.ORG Mon Mar 16 16:59:57 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 698A8106566B; Mon, 16 Mar 2009 16:59:57 +0000 (UTC) (envelope-from lulf@FreeBSD.org) Received: from bene1.itea.ntnu.no (bene1.itea.ntnu.no [IPv6:2001:700:300:3::56]) by mx1.freebsd.org (Postfix) with ESMTP id 2140D8FC25; Mon, 16 Mar 2009 16:59:57 +0000 (UTC) (envelope-from lulf@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by bene1.itea.ntnu.no (Postfix) with ESMTP id 4C06B16C73E; Mon, 16 Mar 2009 17:59:56 +0100 (CET) Received: from carrot (unknown [IPv6:2001:700:300:3::184]) by bene1.itea.ntnu.no (Postfix) with ESMTP id 0828E16C7B2; Mon, 16 Mar 2009 17:59:53 +0100 (CET) Date: Mon, 16 Mar 2009 16:59:57 +0100 From: Ulf Lilleengen To: freebsd-current@freebsd.org Message-ID: <20090316155957.GA2385@carrot> References: <20090316155800.GA2257@carrot> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090316155800.GA2257@carrot> User-Agent: Mutt/1.5.19 (2009-01-05) X-Virus-Scanned: Debian amavisd-new at bene1.itea.ntnu.no Cc: freebsd-geom@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [HEADS UP] Merge of projects/gvinum to head 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: Mon, 16 Mar 2009 16:59:58 -0000 On man, mar 16, 2009 at 04:58:00pm +0100, Ulf Lilleengen wrote: > Hello, > > This is a heads-up for a merge of gvinum project code into HEAD. This means > that gvinum implementation will be changed some. The code is based on the > work done by Lukas Ertl as well as the work I did before/during Google SoC > 2007 and afterwards. It has been staying in p4 for some time, and then moved > to the subversion project repository not long ago. The main reason for the > delay of getting this into HEAD have been the lack of reviewers of the code, > but after some discussion and help from testers, I've decided this is a good > time to get it in (should perhaps have been merged a bit earlier) Testers > have spotted several differences from the original gvinum, and I've tried to > make it behave as the old implementation wherever that seemed the best way to > go. Luckily, the work has gotten a bit of attention lately, thanks to Rick C. > Petty for helping out with testing and bugfixing, as well as all others who > have dared to run the new gvinum. So, what does this update offer? And I plan on importing it within 1-2 weeks :) -- Ulf Lilleengen From owner-freebsd-geom@FreeBSD.ORG Wed Mar 18 15:51:34 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 6C76D106566C for ; Wed, 18 Mar 2009 15:51:34 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A99988FC0A for ; Wed, 18 Mar 2009 15:51:33 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA01758; Wed, 18 Mar 2009 17:51:29 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <49C11880.8000506@freebsd.org> Date: Wed, 18 Mar 2009 17:51:28 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: Marcel Moolenaar References: <4978C24D.9040706@icyb.net.ua> <49A6C33E.70402@freebsd.org> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-geom@freebsd.org Subject: Re: gpart bootcode and /boot/boot 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: Wed, 18 Mar 2009 15:51:35 -0000 on 26/02/2009 18:54 Marcel Moolenaar said the following: > > On Feb 26, 2009, at 8:28 AM, Andriy Gapon wrote: > >> on 22/01/2009 21:00 Andriy Gapon said the following: >>> Sorry for being lazy - what is "gpart bootcode" equivalent of bsdlabel >>> -B [-b boot] ? >>> >> >> Marcel, guys, I am still curious. >> >> disklabel -B refuses do to anything because of what it thinks is >> incorrect >> partition info. >> >> And the following command gets "Operation not permitted" when it opens >> ad6s1 for >> writing: >> gpart bootcode -p /boot/boot -i 1 ad6 > > Don't you mean "gpart bootcode -b /boot/boot ad6s1" > > If you say "-i 1 ad6", then what you want is bootcode > in a partition that is controlled by the scheme on ad6 > (the scheme on ad6 is the MBR). You can't do that, > because that partition is sub-partitioned by the BSD > scheme. > > Since you want bootcode in the BSD scheme, you need > to add bootcode to ad6s1. Thank you very much for the explanation! >> >> This is amd64, stable/7, gpart-only kernel (gpart_mbr, gpart_bsd). > > Bootcode for the BSD scheme is not present in 7-STABLE yet. > I just recently added that to -CURRENT (I must have missed > it) and I need to get around MFCing it. Feel free to do the > MFC for me. The code has been in -CURRENT long enough to do > a MFC. Thank you for the offer and sorry that I haven't used the opportunity. And thank you for the MFC - I am using the code in stable/7 and successfully updated boot2 blocks via the command you suggested. Just for the record - I did it to use jhb's fix for real<->protected switch in boot code. BTW, is there a way to read/backup bootcode (for BSD scheme)? -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Wed Mar 18 16:23:54 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 1DE861065760; Wed, 18 Mar 2009 16:23:54 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout018.mac.com (asmtpout018.mac.com [17.148.16.93]) by mx1.freebsd.org (Postfix) with ESMTP id 08A838FC08; Wed, 18 Mar 2009 16:23:54 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from macbook-pro.jnpr.net ([66.129.224.36]) by asmtp018.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KGP003IGMVDU530@asmtp018.mac.com>; Wed, 18 Mar 2009 09:23:38 -0700 (PDT) Message-id: <0B27FB91-9F2B-4F96-B4A0-330CAD725AF1@mac.com> From: Marcel Moolenaar To: Andriy Gapon In-reply-to: <49C11880.8000506@freebsd.org> Date: Wed, 18 Mar 2009 09:23:01 -0700 References: <4978C24D.9040706@icyb.net.ua> <49A6C33E.70402@freebsd.org> <49C11880.8000506@freebsd.org> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-geom@freebsd.org Subject: Re: gpart bootcode and /boot/boot 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: Wed, 18 Mar 2009 16:23:54 -0000 On Mar 18, 2009, at 8:51 AM, Andriy Gapon wrote: > on 26/02/2009 18:54 Marcel Moolenaar said the following: >> >> On Feb 26, 2009, at 8:28 AM, Andriy Gapon wrote: >> >>> on 22/01/2009 21:00 Andriy Gapon said the following: >>>> Sorry for being lazy - what is "gpart bootcode" equivalent of >>>> bsdlabel >>>> -B [-b boot] ? >>>> >>> >>> Marcel, guys, I am still curious. >>> >>> disklabel -B refuses do to anything because of what it thinks is >>> incorrect >>> partition info. >>> >>> And the following command gets "Operation not permitted" when it >>> opens >>> ad6s1 for >>> writing: >>> gpart bootcode -p /boot/boot -i 1 ad6 >> >> Don't you mean "gpart bootcode -b /boot/boot ad6s1" >> >> If you say "-i 1 ad6", then what you want is bootcode >> in a partition that is controlled by the scheme on ad6 >> (the scheme on ad6 is the MBR). You can't do that, >> because that partition is sub-partitioned by the BSD >> scheme. >> >> Since you want bootcode in the BSD scheme, you need >> to add bootcode to ad6s1. > > > Thank you very much for the explanation! > >>> >>> This is amd64, stable/7, gpart-only kernel (gpart_mbr, gpart_bsd). >> >> Bootcode for the BSD scheme is not present in 7-STABLE yet. >> I just recently added that to -CURRENT (I must have missed >> it) and I need to get around MFCing it. Feel free to do the >> MFC for me. The code has been in -CURRENT long enough to do >> a MFC. > > Thank you for the offer and sorry that I haven't used the opportunity. > And thank you for the MFC - I am using the code in stable/7 and > successfully > updated boot2 blocks via the command you suggested. > Just for the record - I did it to use jhb's fix for real<->protected > switch in > boot code. > > BTW, is there a way to read/backup bootcode (for BSD scheme)? There's no gpart function for it yet, but you can use dd as a work-around. Unfortunately, that means you need to know how much to read: MBR: 1 sector (512B) starting at 0 BSD: 16 sectors (8KB) starting at 0 These raw dumps can be restored using gpart: gpart bootcode -b $mbr.dd ad6 gpart bootcode -b $bsd.dd ad6s1 No, it will not destroy any partitioning data :-) -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-geom@FreeBSD.ORG Wed Mar 18 16:53:35 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 5309F106566C for ; Wed, 18 Mar 2009 16:53:35 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 88D228FC14 for ; Wed, 18 Mar 2009 16:53:34 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA04868; Wed, 18 Mar 2009 18:53:29 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <49C12708.6050702@freebsd.org> Date: Wed, 18 Mar 2009 18:53:28 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: Marcel Moolenaar References: <4978C24D.9040706@icyb.net.ua> <49A6C33E.70402@freebsd.org> <49C11880.8000506@freebsd.org> <0B27FB91-9F2B-4F96-B4A0-330CAD725AF1@mac.com> In-Reply-To: <0B27FB91-9F2B-4F96-B4A0-330CAD725AF1@mac.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-geom@freebsd.org Subject: Re: gpart bootcode and /boot/boot 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: Wed, 18 Mar 2009 16:53:35 -0000 on 18/03/2009 18:23 Marcel Moolenaar said the following: > > On Mar 18, 2009, at 8:51 AM, Andriy Gapon wrote: >> BTW, is there a way to read/backup bootcode (for BSD scheme)? > > There's no gpart function for it yet, but you can use dd > as a work-around. Unfortunately, that means you need to > know how much to read: > MBR: 1 sector (512B) starting at 0 > BSD: 16 sectors (8KB) starting at 0 > > These raw dumps can be restored using gpart: > gpart bootcode -b $mbr.dd ad6 > gpart bootcode -b $bsd.dd ad6s1 > > No, it will not destroy any partitioning data :-) O great, thanks! So gpart simply ignores bytes of "input" data that correspond to partition/label data. Good to know. -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Thu Mar 19 06:07:08 2009 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C802D1065670; Thu, 19 Mar 2009 06:07:08 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 99C258FC08; Thu, 19 Mar 2009 06:07:08 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n2J678Bf041178; Thu, 19 Mar 2009 06:07:08 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n2J678n1041174; Thu, 19 Mar 2009 06:07:08 GMT (envelope-from linimon) Date: Thu, 19 Mar 2009 06:07:08 GMT Message-Id: <200903190607.n2J678n1041174@freefall.freebsd.org> To: stephleg@free.fr, linimon@FreeBSD.org, freebsd-geom@FreeBSD.org, lulf@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/131575: [geom_label] [msdosfs] [umass] Immediate crash after plug of an USB key 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: Thu, 19 Mar 2009 06:07:09 -0000 Synopsis: [geom_label] [msdosfs] [umass] Immediate crash after plug of an USB key State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Thu Mar 19 06:06:26 UTC 2009 State-Changed-Why: Committed and MFCed to 7 by lulf. Responsible-Changed-From-To: freebsd-geom->lulf Responsible-Changed-By: linimon Responsible-Changed-When: Thu Mar 19 06:06:26 UTC 2009 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=131575 From owner-freebsd-geom@FreeBSD.ORG Thu Mar 19 08:33:14 2009 Return-Path: Delivered-To: geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CA0D106564A; Thu, 19 Mar 2009 08:33:14 +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 7B48C8FC1C; Thu, 19 Mar 2009 08:33:13 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id AFE3873098; Thu, 19 Mar 2009 09:19:36 +0100 (CET) Date: Thu, 19 Mar 2009 09:19:36 +0100 From: Luigi Rizzo To: geom@freebsd.org, phk@freebsd.org, ivan@freebsd.org, fabio@gandalf.sssup.it Message-ID: <20090319081936.GA32750@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: arch@freebsd.org, Luigi Rizzo Subject: 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: Thu, 19 Mar 2009 08:33:14 -0000 --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, Fabio Checconi and I have been thinking on how to implement "proxy" geom nodes, i.e. nodes that have exactly 1 provider and 1 consumer port, do not do any data transformation, and can be transparently inserted or removed on top of a provider port while the tree is actively moving data. Our immediate need was to add/remove a scheduler while a disk is mounted, but there are possibly other uses e.g. if one wants to "sniff" the traffic through a disk, or do other ops that are transparent for the data stream. We would like opinion on the following solution, which seems extremely simple in terms of implementation. The idea is to intercept requests coming on a provider port, pp, and redirect them to a geom node acting as a proxy if the port is configured in this way: +=====...===...======+ H H H H H H +=====...====== cp ==+ | +---------------+ V | V +=====.....==== pp ==+ | +======= proxy_pp ==+ H 'ad0s1' H | H H H ------->--+ H H H gp -------<--+ H proxy_node H H H | H H +=======....===...===+ | +======= proxy_cp ==+ | V +---------------+ Normally the proxy does not exist, and the geom tree works as it does now. When we create a 'proxy' node, with something like geom my_proxy_class proxy ad0s1 we do something very similar to a 'create', but: - the proxy node is marked specially in gp->flags, so the core will not generate a g_new_provider_event when the provider port is created (this means there is no taste() call and nobody should be able to attach to the port). - the provider port we attach to is linked, with two pointers, to the provider and consumer ports of the proxy_node. In this situation, g_io_request() finds that port pp has a proxy attached to it, and immediately redirects the requests to the proxy, which does everything a geom node does (cloning requests, etc). When the proxy wants to pass the request down, it sends it again to pp, but now there is no redirection because the source can be identified as the proxy. The pointers in the bio insure a correct flow of the requests on the reverse path. Disconnecting a proxy is almost trivial: apart from handling possible races on the data path, we just need to clear pp->proxy_pp and pp->proxy_cp. After that, we can just send the regular destroy events to the proxy node, who will have to take care of flushing any pending bio's (e.g. see our geom_sched node that already does this). Overall the change is very small (see attached patch): a couple of lines in g_io_request, two extra fields in the g_provider, and the addition of a flag to gp->flags to control the generation of g_new_provider_event. There is basically no overhead on regular operation, and only a couple of extra pointers in struct g_provider (we use a spare bit in gp->flags to mark G_GEOM_PROXY nodes). The only things missing in the patch should be: - a check to avoid races on creation&destruction of a proxy. I am not so sure on how to achieve this, but creation and destruction are rare and can normally wait, so we could just piggyback the small critical section (manipulating pp->proxy_cp and pp->proxy_cp) into some other piece of code that is guaranteed to be race-free. - a check to prevent attaching to a provider port of a proxy (not a problem, i believe); - a check to prevent attaching a proxy to a provider port that already has one. Of course you can attach a proxy to another proxy, and if you want to change the order it is as simple as removing the existing proxy and reattaching it after the new one. Feedback welcome. cheers luigi and fabio --J/dobhs11T7y2rNN-- From owner-freebsd-geom@FreeBSD.ORG Thu Mar 19 10:12:00 2009 Return-Path: Delivered-To: geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65EFD1065672; Thu, 19 Mar 2009 10:12:00 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045082.chello.pl [87.206.45.82]) by mx1.freebsd.org (Postfix) with ESMTP id C56DB8FC24; Thu, 19 Mar 2009 10:11:59 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id BC16D45C98; Thu, 19 Mar 2009 10:44:30 +0100 (CET) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 4A34D45B26; Thu, 19 Mar 2009 10:44:25 +0100 (CET) Date: Thu, 19 Mar 2009 10:45:05 +0100 From: Pawel Jakub Dawidek To: Luigi Rizzo Message-ID: <20090319094505.GA1539@garage.freebsd.pl> References: <20090319081936.GA32750@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Dxnq1zWXvFF0Q93v" Content-Disposition: inline In-Reply-To: <20090319081936.GA32750@onelab2.iet.unipi.it> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: fabio@gandalf.sssup.it, geom@freebsd.org, arch@freebsd.org, phk@freebsd.org, ivan@freebsd.org Subject: 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: Thu, 19 Mar 2009 10:12:00 -0000 --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 19, 2009 at 09:19:36AM +0100, Luigi Rizzo wrote: > Hi, >=20 > Fabio Checconi and I have been thinking on how to implement "proxy" > geom nodes, i.e. nodes that have exactly 1 provider and 1 consumer > port, do not do any data transformation, and can be transparently > inserted or removed on top of a provider port while the tree is > actively moving data. >=20 > Our immediate need was to add/remove a scheduler while a disk is > mounted, but there are possibly other uses e.g. if one wants to > "sniff" the traffic through a disk, or do other ops that are > transparent for the data stream. >=20 > We would like opinion on the following solution, which seems > extremely simple in terms of implementation. >=20 > The idea is to intercept requests coming on a provider port, pp, and > redirect them to a geom node acting as a proxy if the port > is configured in this way: >=20 > +=3D=3D=3D=3D=3D...=3D=3D=3D...=3D=3D=3D=3D=3D=3D+ > H H > H H > H H > +=3D=3D=3D=3D=3D...=3D=3D=3D=3D=3D=3D cp =3D=3D+ > | +---------------+ > V | V > +=3D=3D=3D=3D=3D.....=3D=3D=3D=3D pp =3D=3D+ | +=3D=3D=3D=3D= =3D=3D=3D proxy_pp =3D=3D+ > H 'ad0s1' H | H H > H ------->--+ H H > H gp -------<--+ H proxy_node H > H H | H H > +=3D=3D=3D=3D=3D=3D=3D....=3D=3D=3D...=3D=3D=3D+ | +=3D=3D=3D= =3D=3D=3D=3D proxy_cp =3D=3D+ > | V > +---------------+ >=20 > Normally the proxy does not exist, and the geom tree works as it does now. >=20 > When we create a 'proxy' node, with something like >=20 > geom my_proxy_class proxy ad0s1 >=20 > we do something very similar to a 'create', but: >=20 > - the proxy node is marked specially in gp->flags, so the core will > not generate a g_new_provider_event when the provider port is created > (this means there is no taste() call and nobody should be able > to attach to the port). >=20 > - the provider port we attach to is linked, with two pointers, > to the provider and consumer ports of the proxy_node. >=20 > In this situation, g_io_request() finds that port pp has a proxy attached > to it, and immediately redirects the requests to the proxy, which > does everything a geom node does (cloning requests, etc). > When the proxy wants to pass the request down, it sends it again to pp, > but now there is no redirection because the source can be identified > as the proxy. The pointers in the bio insure a correct flow of the > requests on the reverse path. The one advantage I see for this over using regular GEOM rules is that new consumers go through proxy automatically. When I was working on similar functionality I more wanted to do something like this: consumer1 consumer2 \ / \ / provider Insert the proxy in the middle of any provider-consumer pair: consumer1 consumer2 | | proxy_provider | | / proxy_consumer / \ / provider This can be done (almost I think) atomically: /* First attach to the destination provider. */ g_attach(proxy_consumer, provider); /* Then switch original consumer to use proxy_provider (should be almost at= omic). */ consumer1->provider =3D proxy_provider; /* handle access counts */ In-flight I/O requests know how to go back, because they have source and destination stored in bio_from and bio_to fields, so no races here. > Disconnecting a proxy is almost trivial: apart from handling possible > races on the data path, we just need to clear pp->proxy_pp and pp->proxy_= cp. > After that, we can just send the regular destroy events to the proxy > node, who will have to take care of flushing any pending bio's (e.g. > see our geom_sched node that already does this). >=20 > Overall the change is very small (see attached patch): > a couple of lines in g_io_request, two extra fields in the g_provider, > and the addition of a flag to gp->flags to control the generation > of g_new_provider_event. > There is basically no overhead on regular operation, and only > a couple of extra pointers in struct g_provider (we use a spare > bit in gp->flags to mark G_GEOM_PROXY nodes). >=20 > The only things missing in the patch should be: >=20 > - a check to avoid races on creation&destruction of a proxy. > I am not so sure on how to achieve this, but creation and destruction > are rare and can normally wait, so we could just piggyback the > small critical section (manipulating pp->proxy_cp and pp->proxy_cp) > into some other piece of code that is guaranteed to be race-free. >=20 > - a check to prevent attaching to a provider port of a proxy > (not a problem, i believe); >=20 > - a check to prevent attaching a proxy to a provider port that already > has one. Of course you can attach a proxy to another proxy, and > if you want to change the order it is as simple as removing the > existing proxy and reattaching it after the new one. Could you provide link for the patch, as it was removed from your e-mail? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --Dxnq1zWXvFF0Q93v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFJwhQhForvXbEpPzQRAqtkAJ9zME7wMe4RZMsBYdAURm/9voIr/QCgwAim NK2iPFV6J/jPGqpLNhH3Cl8= =Fzxm -----END PGP SIGNATURE----- --Dxnq1zWXvFF0Q93v-- From owner-freebsd-geom@FreeBSD.ORG Thu Mar 19 11:08:53 2009 Return-Path: Delivered-To: geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 500691065670; Thu, 19 Mar 2009 11:08:53 +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 110AD8FC23; Thu, 19 Mar 2009 11:08:52 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 1FECC73098; Thu, 19 Mar 2009 12:13:39 +0100 (CET) Date: Thu, 19 Mar 2009 12:13:39 +0100 From: Luigi Rizzo To: Pawel Jakub Dawidek Message-ID: <20090319111339.GA38075@onelab2.iet.unipi.it> References: <20090319081936.GA32750@onelab2.iet.unipi.it> <20090319094505.GA1539@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090319094505.GA1539@garage.freebsd.pl> User-Agent: Mutt/1.4.2.3i Cc: fabio@gandalf.sssup.it, geom@FreeBSD.org, phk@FreeBSD.org, arch@FreeBSD.org, ivan@FreeBSD.org Subject: 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: Thu, 19 Mar 2009 11:08:53 -0000 On Thu, Mar 19, 2009 at 10:45:05AM +0100, Pawel Jakub Dawidek wrote: > > Hi, > > > > Fabio Checconi and I have been thinking on how to implement "proxy" > > geom nodes, i.e. nodes that have exactly 1 provider and 1 consumer > > port, do not do any data transformation, and can be transparently > > inserted or removed on top of a provider port while the tree is > > actively moving data. ... > > Overall the change is very small (see attached patch): > > a couple of lines in g_io_request, two extra fields in the g_provider, > > and the addition of a flag to gp->flags to control the generation > > of g_new_provider_event. It seems that the attachment was removed so here it is http://info.iet.unipi.it/~luigi/FreeBSD/20090319-geom-proxy.patch cheers luigi From owner-freebsd-geom@FreeBSD.ORG Thu Mar 19 11:17:07 2009 Return-Path: Delivered-To: geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE42A106566B; Thu, 19 Mar 2009 11:17:07 +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 7A85F8FC0A; Thu, 19 Mar 2009 11:17:07 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id A686973098; Thu, 19 Mar 2009 12:21:52 +0100 (CET) Date: Thu, 19 Mar 2009 12:21:52 +0100 From: Luigi Rizzo To: Pawel Jakub Dawidek Message-ID: <20090319112152.GB38075@onelab2.iet.unipi.it> References: <20090319081936.GA32750@onelab2.iet.unipi.it> <20090319094505.GA1539@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090319094505.GA1539@garage.freebsd.pl> User-Agent: Mutt/1.4.2.3i Cc: fabio@gandalf.sssup.it, geom@FreeBSD.org, phk@FreeBSD.org, arch@FreeBSD.org, ivan@FreeBSD.org Subject: 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: Thu, 19 Mar 2009 11:17:08 -0000 On Thu, Mar 19, 2009 at 10:45:05AM +0100, Pawel Jakub Dawidek wrote: > On Thu, Mar 19, 2009 at 09:19:36AM +0100, Luigi Rizzo wrote: ... > The one advantage I see for this over using regular GEOM rules is that > new consumers go through proxy automatically. When I was working on > similar functionality I more wanted to do something like this: > > consumer1 consumer2 > \ / > \ / > provider > > Insert the proxy in the middle of any provider-consumer pair: > > consumer1 consumer2 > | | > proxy_provider | > | / > proxy_consumer / > \ / > provider ok this is slightly different from what we have implemented, as we hook into the provider whereas you hook into the consumer. In our case we really need the hook to be in the provider so it intercepts accesses from all consumers, e.g. from /dev/ad0 and from the filesystems mounted on top of it. Given that the geom_disk node does not have a consumer on the bottom, we cannot do it differently. I can imagine that one might want to attach a proxy to a consumer port, but I cannot make a specific case where this would be needed. Also, I wonder how do i name a consumer port in the geom model ?? cheers luigi From owner-freebsd-geom@FreeBSD.ORG Thu Mar 19 12:05:58 2009 Return-Path: Delivered-To: geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0831F10659E1 for ; Thu, 19 Mar 2009 12:05:58 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id 7B6408FC29 for ; Thu, 19 Mar 2009 12:05:57 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: by fg-out-1718.google.com with SMTP id 19so60971fgg.12 for ; Thu, 19 Mar 2009 05:05:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.96.1 with SMTP id t1mr243342fgb.46.1237462873065; Thu, 19 Mar 2009 04:41:13 -0700 (PDT) In-Reply-To: <20090319081936.GA32750@onelab2.iet.unipi.it> References: <20090319081936.GA32750@onelab2.iet.unipi.it> Date: Thu, 19 Mar 2009 12:41:13 +0100 Message-ID: From: =?ISO-8859-1?Q?Marius_N=FCnnerich?= To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: fabio@gandalf.sssup.it, geom@freebsd.org, arch@freebsd.org, phk@freebsd.org, ivan@freebsd.org Subject: 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: Thu, 19 Mar 2009 12:06:32 -0000 2009/3/19 Luigi Rizzo : > Hi, > > Fabio Checconi and I have been thinking on how to implement "proxy" > geom nodes, i.e. nodes that have exactly 1 provider and 1 consumer > port, do not do any data transformation, and can be transparently > inserted or removed on top of a provider port while the tree is > actively moving data. > > Our immediate need was to add/remove a scheduler while a disk is > mounted, but there are possibly other uses e.g. if one wants to > "sniff" the traffic through a disk, or do other ops that are > transparent for the data stream. > > We would like opinion on the following solution, which seems > extremely simple in terms of implementation. > > The idea is to intercept requests coming on a provider port, pp, and > redirect them to a geom node acting as a proxy if the port > is configured in this way: > > =A0 =A0 +=3D=3D=3D=3D=3D...=3D=3D=3D...=3D=3D=3D=3D=3D=3D+ > =A0 =A0 H =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0H > =A0 =A0 H =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0H > =A0 =A0 H =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0H > =A0 =A0 +=3D=3D=3D=3D=3D...=3D=3D=3D=3D=3D=3D cp =3D=3D+ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0+-----------= ----+ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 V =A0 =A0 =A0 =A0 =A0| =A0 =A0 = =A0 =A0 =A0 =A0 =A0 V > =A0 =A0 +=3D=3D=3D=3D=3D.....=3D=3D=3D=3D pp =3D=3D+ =A0 =A0 | =A0 =A0+= =3D=3D=3D=3D=3D=3D=3D proxy_pp =3D=3D+ > =A0 =A0 H =A0 =A0 =A0 =A0 =A0 'ad0s1' =A0H =A0 =A0 | =A0 =A0H =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 H > =A0 =A0 H =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0------->--+ =A0 =A0H =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 H > =A0 =A0 H =A0 =A0 =A0 =A0gp =A0 =A0 =A0-------<--+ =A0 =A0H =A0 =A0proxy_= node =A0 =A0 H > =A0 =A0 H =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0H =A0 =A0 | =A0 =A0H =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 H > =A0 =A0 +=3D=3D=3D=3D=3D=3D=3D....=3D=3D=3D...=3D=3D=3D+ =A0 =A0 | =A0 = =A0+=3D=3D=3D=3D=3D=3D=3D proxy_cp =3D=3D+ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 = =A0 =A0 =A0 =A0 =A0 V > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+---------= ------+ > > Normally the proxy does not exist, and the geom tree works as it does now= . > > When we create a 'proxy' node, with something like > > =A0 =A0 =A0 =A0geom my_proxy_class proxy ad0s1 > > we do something very similar to a 'create', but: > > - the proxy node is marked specially in gp->flags, so the core will > =A0not generate a g_new_provider_event when the provider port is created > =A0(this means there is no taste() call and nobody should be able > =A0to attach to the port). > > - the provider port we attach to is linked, with two pointers, > =A0to the provider and consumer ports of the proxy_node. > > In this situation, g_io_request() finds that port pp has a proxy attached > to it, and immediately redirects the requests to the proxy, which > does everything a geom node does (cloning requests, etc). > =A0 When the proxy wants to pass the request down, it sends it again to p= p, > but now there is no redirection because the source can be identified > as the proxy. =A0The pointers in the bio insure a correct flow of the > requests on the reverse path. > > Disconnecting a proxy is almost trivial: apart from handling possible > races on the data path, we just need to clear pp->proxy_pp and pp->proxy_= cp. > After that, we can just send the regular destroy events to the proxy > node, who will have to take care of flushing any pending bio's (e.g. > see our geom_sched node that already does this). > > Overall the change is very small (see attached patch): > a couple of lines in g_io_request, two extra fields in the g_provider, > and the addition of a flag to gp->flags to control the generation > of g_new_provider_event. > There is basically no overhead on regular operation, and only > a couple of extra pointers in struct g_provider (we use a spare > bit in gp->flags to mark G_GEOM_PROXY nodes). > > The only things missing in the patch should be: > > - a check to avoid races on creation&destruction of a proxy. > =A0I am not so sure on how to achieve this, but creation and destruction > =A0are rare and can normally wait, so we could just piggyback the > =A0small critical section (manipulating pp->proxy_cp and pp->proxy_cp) > =A0into some other piece of code that is guaranteed to be race-free. > > - a check to prevent attaching to a provider port of a proxy > =A0(not a problem, i believe); > > - a check to prevent attaching a proxy to a provider port that already > =A0has one. Of course you can attach a proxy to another proxy, and > =A0if you want to change the order it is as simple as removing the > =A0existing proxy and reattaching it after the new one. > > Feedback welcome. I wonder if it's really necessary to alter the GEOM infrastructure or if it is possible to do this with what's there already. Just an idea: Lock g_topology, put g_down and g_up to sleep, alter the consumer and provider pointers where you need it so the everything is routed through your proxy class (which isn't special in any way) and restart g_down and g_up. From owner-freebsd-geom@FreeBSD.ORG Thu Mar 19 12:56:51 2009 Return-Path: Delivered-To: geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA7A3106566C; Thu, 19 Mar 2009 12:56:51 +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 8A8398FC12; Thu, 19 Mar 2009 12:56:51 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id E49C6730A4; Thu, 19 Mar 2009 14:01:37 +0100 (CET) Date: Thu, 19 Mar 2009 14:01:37 +0100 From: Luigi Rizzo To: Marius N?nnerich Message-ID: <20090319130137.GB40489@onelab2.iet.unipi.it> References: <20090319081936.GA32750@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: fabio@gandalf.sssup.it, geom@freebsd.org, arch@freebsd.org, phk@freebsd.org, ivan@freebsd.org Subject: 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: Thu, 19 Mar 2009 12:56:52 -0000 On Thu, Mar 19, 2009 at 12:41:13PM +0100, Marius N?nnerich wrote: > 2009/3/19 Luigi Rizzo : > > Hi, > > > > Fabio Checconi and I have been thinking on how to implement "proxy" > > geom nodes, i.e. nodes that have exactly 1 provider and 1 consumer > > port, do not do any data transformation, and can be transparently > > inserted or removed on top of a provider port while the tree is > > actively moving data. ... > > The idea is to intercept requests coming on a provider port, pp, and > > redirect them to a geom node acting as a proxy if the port > > is configured in this way: ... > I wonder if it's really necessary to alter the GEOM infrastructure or > if it is possible to do this with what's there already. Just an idea: > Lock g_topology, put g_down and g_up to sleep, alter the consumer and > provider pointers where you need it so the everything is routed > through your proxy class (which isn't special in any way) and restart > g_down and g_up. we'll look into this, thanks. If we can spare the extra fields in the g_provider, the thing is even easier to do. I just don't know how your suggestion interferes with the naming: if I change the pointers, the name of a provider will not be anymore a prefix of the name of the node attached above. But maybe that is not an architectural requirements but just a convenient convention. cheers luigi From owner-freebsd-geom@FreeBSD.ORG Fri Mar 20 19:08:29 2009 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 631241065670; Fri, 20 Mar 2009 19:08:29 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 384218FC17; Fri, 20 Mar 2009 19:08:29 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n2KJ8T7B039997; Fri, 20 Mar 2009 19:08:29 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n2KJ8T6k039993; Fri, 20 Mar 2009 19:08:29 GMT (envelope-from linimon) Date: Fri, 20 Mar 2009 19:08:29 GMT Message-Id: <200903201908.n2KJ8T6k039993@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-geom@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: bin/132845: [geom] [patch] ggated(8) does not close files opened after disconnect 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: Fri, 20 Mar 2009 19:08:30 -0000 Synopsis: [geom] [patch] ggated(8) does not close files opened after disconnect Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: linimon Responsible-Changed-When: Fri Mar 20 19:08:18 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=132845 From owner-freebsd-geom@FreeBSD.ORG Sat Mar 21 00:08:20 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 970A71065678 for ; Sat, 21 Mar 2009 00:08:20 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 1B8CF8FC17 for ; Sat, 21 Mar 2009 00:08:19 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LkoF7-0005cH-Fx for freebsd-geom@freebsd.org; Fri, 20 Mar 2009 23:35:13 +0000 Received: from 93-141-34-15.adsl.net.t-com.hr ([93.141.34.15]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Mar 2009 23:35:13 +0000 Received: from ivoras by 93-141-34-15.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Mar 2009 23:35:13 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Sat, 21 Mar 2009 00:34:37 +0100 Lines: 58 Message-ID: References: <20090319081936.GA32750@onelab2.iet.unipi.it> <20090319130137.GB40489__3492.42561865157$1237467521$gmane$org@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBF64D510A73AEB49CE90CB48" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 93-141-34-15.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <20090319130137.GB40489__3492.42561865157$1237467521$gmane$org@onelab2.iet.unipi.it> X-Enigmail-Version: 0.95.7 Sender: news Subject: 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: Sat, 21 Mar 2009 00:08:22 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBF64D510A73AEB49CE90CB48 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Luigi Rizzo wrote: > On Thu, Mar 19, 2009 at 12:41:13PM +0100, Marius N?nnerich wrote: >> 2009/3/19 Luigi Rizzo : >>> Hi, >>> >>> Fabio Checconi and I have been thinking on how to implement "proxy" >>> geom nodes, i.e. nodes that have exactly 1 provider and 1 consumer >>> port, do not do any data transformation, and can be transparently >>> inserted or removed on top of a provider port while the tree is >>> actively moving data. > ... >>> The idea is to intercept requests coming on a provider port, pp, and >>> redirect them to a geom node acting as a proxy if the port >>> is configured in this way: > ... >> I wonder if it's really necessary to alter the GEOM infrastructure or >> if it is possible to do this with what's there already. Just an idea: >> Lock g_topology, put g_down and g_up to sleep, alter the consumer and >> provider pointers where you need it so the everything is routed >> through your proxy class (which isn't special in any way) and restart >> g_down and g_up. >=20 > we'll look into this, thanks. If we can spare the extra fields > in the g_provider, the thing is even easier to do. >=20 > I just don't know how your suggestion interferes with the naming: > if I change the pointers, the name of a provider will not > be anymore a prefix of the name of the node attached above. > But maybe that is not an architectural requirements but just > a convenient convention. Not only with naming and device creation - the proxy classes cannot be "normal" classes because it's common that "normal" classes do a lot of initialization in .taste. (i.e. there at least needs to be a flag for proxy classes) --------------enigBF64D510A73AEB49CE90CB48 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknEKBUACgkQldnAQVacBchKhwCg71ft9Jn6NaT9MErBc0PI0IN2 hakAoJrO2DBaW2YjDk0nbM3B2YMsP+Zw =cpco -----END PGP SIGNATURE----- --------------enigBF64D510A73AEB49CE90CB48-- From owner-freebsd-geom@FreeBSD.ORG Sat Mar 21 01:25:23 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 44A0A1065670 for ; Sat, 21 Mar 2009 01:25:23 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: from mail-bw0-f164.google.com (mail-bw0-f164.google.com [209.85.218.164]) by mx1.freebsd.org (Postfix) with ESMTP id D1CBA8FC08 for ; Sat, 21 Mar 2009 01:25:22 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: by bwz8 with SMTP id 8so1030700bwz.43 for ; Fri, 20 Mar 2009 18:25:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.55.142 with SMTP id u14mr1450205bkg.121.1237597059297; Fri, 20 Mar 2009 17:57:39 -0700 (PDT) In-Reply-To: References: <20090319081936.GA32750@onelab2.iet.unipi.it> <20090319130137.GB40489__3492.42561865157$1237467521$gmane$org@onelab2.iet.unipi.it> Date: Sat, 21 Mar 2009 01:57:39 +0100 Message-ID: From: =?ISO-8859-1?Q?Marius_N=FCnnerich?= To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-geom@freebsd.org Subject: 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: Sat, 21 Mar 2009 01:25:23 -0000 On Sat, Mar 21, 2009 at 00:34, Ivan Voras wrote: > Luigi Rizzo wrote: >> On Thu, Mar 19, 2009 at 12:41:13PM +0100, Marius N?nnerich wrote: >>> 2009/3/19 Luigi Rizzo : >>>> Hi, >>>> >>>> Fabio Checconi and I have been thinking on how to implement "proxy" >>>> geom nodes, i.e. nodes that have exactly 1 provider and 1 consumer >>>> port, do not do any data transformation, and can be transparently >>>> inserted or removed on top of a provider port while the tree is >>>> actively moving data. >> ... >>>> The idea is to intercept requests coming on a provider port, pp, and >>>> redirect them to a geom node acting as a proxy if the port >>>> is configured in this way: >> ... >>> I wonder if it's really necessary to alter the GEOM infrastructure or >>> if it is possible to do this with what's there already. Just an idea: >>> Lock g_topology, put g_down and g_up to sleep, alter the consumer and >>> provider pointers where you need it so the everything is routed >>> through your proxy class (which isn't special in any way) and restart >>> g_down and g_up. >> >> we'll look into this, thanks. If we can spare the extra fields >> in the g_provider, the thing is even easier to do. >> >> I just don't know how your suggestion interferes with the naming: >> if I change the pointers, the name of a provider will not >> be anymore a prefix of the name of the node attached above. >> But maybe that is not an architectural requirements but just >> a convenient convention. > > Not only with naming and device creation - the proxy classes cannot be > "normal" classes because it's common that "normal" classes do a lot of > initialization in .taste. (i.e. there at least needs to be a flag for > proxy classes) Take a look at geom_nop, it doesn't taste. It is like a proxy already as far as I can see. I don't know what to do about the naming though. From owner-freebsd-geom@FreeBSD.ORG Sat Mar 21 11:46:11 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 4362A106566B for ; Sat, 21 Mar 2009 11:46:11 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by mx1.freebsd.org (Postfix) with ESMTP id D05FB8FC0C for ; Sat, 21 Mar 2009 11:46:10 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by fxm11 with SMTP id 11so1125837fxm.43 for ; Sat, 21 Mar 2009 04:46:09 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20090319081936.GA32750@onelab2.iet.unipi.it> <20090319130137.GB40489__3492.42561865157$1237467521$gmane$org@onelab2.iet.unipi.it> Date: Sat, 21 Mar 2009 12:20:04 +0100 Received: by 10.204.69.133 with SMTP id z5mr1640700bki.163.1237634419255; Sat, 21 Mar 2009 04:20:19 -0700 (PDT) Message-ID: <9bbcef730903210420l132c5287yb0a474901424b7da@mail.gmail.com> From: Ivan Voras To: =?UTF-8?Q?Marius_N=C3=BCnnerich?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-geom@freebsd.org Subject: 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: Sat, 21 Mar 2009 11:46:11 -0000 2009/3/21 Marius N=C3=BCnnerich : > Take a look at geom_nop, it doesn't taste. It is like a proxy already > as far as I can see. I don't know what to do about the naming though. Maybe I expressed it wrongly - what I meant to say is that existing "normal" GEOM classes, even if they are proxy-like in nature (like GELI) cannot simply "be used" as a proxy in this context. From owner-freebsd-geom@FreeBSD.ORG Sat Mar 21 20:20:36 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 EB6E4106568A; Sat, 21 Mar 2009 20:20:35 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045082.chello.pl [87.206.45.82]) by mx1.freebsd.org (Postfix) with ESMTP id AFCFF8FC0A; Sat, 21 Mar 2009 20:20:34 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id D34C945685; Sat, 21 Mar 2009 21:03:05 +0100 (CET) Received: from localhost (chello087206045082.chello.pl [87.206.45.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 1988C45683; Sat, 21 Mar 2009 21:02:57 +0100 (CET) Date: Sat, 21 Mar 2009 21:03:34 +0100 From: Pawel Jakub Dawidek To: Ivan Voras Message-ID: <20090321200334.GB3102@garage.freebsd.pl> References: <20090319081936.GA32750@onelab2.iet.unipi.it> <20090319130137.GB40489__3492.42561865157$1237467521$gmane$org@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tqI+Z3u+9OQ7kwn0" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: luigi@FreeBSD.org, phk@FreeBSD.org, freebsd-geom@freebsd.org Subject: 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: Sat, 21 Mar 2009 20:20:38 -0000 --tqI+Z3u+9OQ7kwn0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 21, 2009 at 12:34:37AM +0100, Ivan Voras wrote: > Not only with naming and device creation - the proxy classes cannot be > "normal" classes because it's common that "normal" classes do a lot of > initialization in .taste. (i.e. there at least needs to be a flag for > proxy classes) There are many leaf GEOM classes where taste is never used and also non-leaf classes that don't use tasting (like gbde or geli). Those aren't special GEOM classes in any way. I recommend reading phk's GEOM tutorial from BSDCon 2003. You can find an interesting slide which seems to sum up this thread quite nicely: Special GEOM classes. --------------------- - There are no special GEOM classes. I wonder if phk changed his opinion over time. :) Maybe instead of adding special providers and GEOM classes, the infrastructure should be extended in some way, so that we won't use provider term to describe something that isn't really a regular GEOM provider. On the other hand disk scheduler provides kind of transformation, the only real problem is usability - doing it in the same way as the other GEOM classes will make it much more problematic to use. Current patch makes it much easier to use, but violates infrastructure. Another thing came to my mind. Currently GEOM does nothing to prevent situation where there are two GEOM providers using the same name - we just end up with two /dev/foo entires which is a bit surprising. I was wondering if we couldn't clean this up (at least partially) and implement insert/remove functionality for GEOM in one go. For example we have /dev/ad0 provider created by the DISK class. We create another provider /dev/ad0 of SCHED class. Then we insert SCHED:/dev/ad0 on top of DISK:/dev/ad0. GEOM will reconnect all existing consumers from DISK:/dev/ad0 to SCHED:/dev/ad0 and connect SCHED consumer to DISK:/dev/ad0. Also, GEOM will show only one /dev/ad0 entry in /dev/ - the one which comes from a geom with higher rank count. Now whoever wants to open /dev/ad0 will end up opening SCHED:/dev/ad0 (so there won't be a problem with new consumers). Of course providers that come from geoms with the same rank count would still be a problem, but... Also instead of rank count we could only allow connected providers to cover their children. What do you guys think? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --tqI+Z3u+9OQ7kwn0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFJxUgWForvXbEpPzQRAgusAJ9CuyQCglytexSqaGymGpgE0XocFQCgtH4D OxsTYEHDdFBRZTH+ojl2gMw= =wUBW -----END PGP SIGNATURE----- --tqI+Z3u+9OQ7kwn0-- From owner-freebsd-geom@FreeBSD.ORG Sat Mar 21 20:43:08 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 41F49106566C; Sat, 21 Mar 2009 20:43:08 +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 03B6B8FC17; Sat, 21 Mar 2009 20:43:07 +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 1BAAD3F129; Sat, 21 Mar 2009 20:24:11 +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 n2LKOAh3042966; Sat, 21 Mar 2009 20:24:10 GMT (envelope-from phk@critter.freebsd.dk) To: Pawel Jakub Dawidek From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 21 Mar 2009 21:03:34 +0100." <20090321200334.GB3102@garage.freebsd.pl> Date: Sat, 21 Mar 2009 20:24:10 +0000 Message-ID: <42965.1237667050@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: luigi@FreeBSD.org, Ivan Voras , freebsd-geom@FreeBSD.org Subject: 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: Sat, 21 Mar 2009 20:43:08 -0000 In message <20090321200334.GB3102@garage.freebsd.pl>, Pawel Jakub Dawidek write s: > Special GEOM classes. > --------------------- > > - There are no special GEOM classes. > >I wonder if phk changed his opinion over time. :) He didn't. >Maybe instead of adding special providers and GEOM classes, the >infrastructure should be extended in some way, so that we won't use >provider term to describe something that isn't really a regular GEOM >provider. I have not had time to read this entire thread, being somewhat snowed under with work elsewhere. First up, I am not sure I understand why the proxy nodes would be the (or even 'a') right solution for I/O scheduling. In fact, it is not very clear to me at all that scheduling should happen inside geom at all. I would tend to think that it belongs in the devicedriver, where intelligent information about things like tagged queuing abilities can be taken into account. For any kind of scheduling to do anything non-trivial, requests needs to be piled up so they can be reordered, doing that in places where bio's dont naturally pile up would require a damn good argument and strong numbers to convince me. Where the already do pile up, the existing disksort mechanism and API can be used. (If you want to mess with the disksort *algorithm*, by all means do so, but that should not require you to hack up any apis, apart from the one to select algorithm). With that said: I always envisioned the ability to insert and delete transparant nodes, with the poster boy example being: insert a mirror geom add a mirror on some other provider sync them. delete the old mirro copy pull the mirror mirror geom out again and (tada!) you have migrated a live partition from one disk to another. For that to work, the new class has to end up between the consumer(s) and the geom-class, and I generally planned to stick a {geom-consumer-provider} combination in between the provider and its class, rather than a {provider-geom-consumer} between the consumer and its provider. The reason for this, is that it can be done without stalling the I/O stream since bios all have built in return tickets. So I think, my opinion on this proposal is: 1. Why would you do scheduling in the middle of the GEOM mesh ?? Very strong arguments and numbers will have to be forwarded for that to be a reason to deviate from: 2. There still are not, and should not be created any special GEOM classes. GEOM derives much of it's strength from the fact that there are no special cases to handle, that shouldn't be sold too cheaply. 3. Do it properly instead: Implement the general insert/remove properly, so that we can do things like the "move" example above. 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. From owner-freebsd-geom@FreeBSD.ORG Sat Mar 21 21:47:26 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 F361F106566B for ; Sat, 21 Mar 2009 21:47:25 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7A3C08FC08 for ; Sat, 21 Mar 2009 21:47:25 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ll92H-000853-RM for freebsd-geom@freebsd.org; Sat, 21 Mar 2009 21:47:21 +0000 Received: from 93-141-99-248.adsl.net.t-com.hr ([93.141.99.248]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 21 Mar 2009 21:47:21 +0000 Received: from ivoras by 93-141-99-248.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 21 Mar 2009 21:47:21 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Sat, 21 Mar 2009 22:46:56 +0100 Lines: 112 Message-ID: References: <20090321200334.GB3102@garage.freebsd.pl> <42965.1237667050@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig489BDBA41EDF048D75E21F0D" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 93-141-99-248.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <42965.1237667050@critter.freebsd.dk> X-Enigmail-Version: 0.95.7 Sender: news Subject: 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: Sat, 21 Mar 2009 21:47:26 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig489BDBA41EDF048D75E21F0D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Poul-Henning Kamp wrote: > In message <20090321200334.GB3102@garage.freebsd.pl>, Pawel Jakub Dawid= ek write > s: >=20 >> Special GEOM classes. >> --------------------- >> >> - There are no special GEOM classes. >> >> I wonder if phk changed his opinion over time. :) >=20 > He didn't. Well, let's not call them "GEOM classes" then - call them "GEOM proxies" :) Seriously, *if* there should be things like they are described in this thread, we should write down what they should do and then decide if it's worth reusing the "GEOM class" name and infrastructure. My attempt at this (still under the *if* part) is: * They should probably modify bio's in-place, if it's possible, or in some other way ensure 1:1 mapping of the IO requests that pass through th= em * The following "GEOM class" and "GEOM instance" methods are NOT needed: destroy_geom, taste, access, dumpconf * ... the following ARE needed: ctlreq, start, stop * ... the following may be needed: init, fini, orphan, spoiled (I'm trying to keep them light-weight :) ). >> Maybe instead of adding special providers and GEOM classes, the >> infrastructure should be extended in some way, so that we won't use >> provider term to describe something that isn't really a regular GEOM >> provider. >=20 > I have not had time to read this entire thread, being somewhat > snowed under with work elsewhere. >=20 > First up, I am not sure I understand why the proxy nodes would > be the (or even 'a') right solution for I/O scheduling. >=20 > In fact, it is not very clear to me at all that scheduling should > happen inside geom at all. >=20 > I would tend to think that it belongs in the devicedriver, where > intelligent information about things like tagged queuing abilities > can be taken into account. Except for "dumb" controllers and/or drivers. AFAIK our ATA doesn't do NC= Q. > For any kind of scheduling to do anything non-trivial, requests > needs to be piled up so they can be reordered, doing that in > places where bio's dont naturally pile up would require a damn > good argument and strong numbers to convince me. > > Where the already do pile up, the existing disksort mechanism > and API can be used. (If you want to mess with the disksort > *algorithm*, by all means do so, but that should not require > you to hack up any apis, apart from the one to select algorithm). Well, each layer in common Intel servers today does its own scheduling: * The OS - it's was a big deal when Linux and Vista implemented them * The (smart) disk controllers * The drives themselves. I don't know enough to clam it is good or bad, but there's probably something in there. > 2. There still are not, and should not be created any special GEOM > classes. GEOM derives much of it's strength from the fact that > there are no special cases to handle, that shouldn't be sold > too cheaply. > 3. Do it properly instead: Implement the general insert/remove > properly, so that we can do things like the "move" example above. Doesn't the inclusion of "hot-swappiness" in the topology tree mean that either the existing classes need to be modified extensively, or that there must be some kind of flag telling which classes support this mechanism and which don't, effectively segregating them? Also, some classes don't have a meaning in the "proxy" context, like stripe, concat, raid3, vinum, etc. What I'm trying to say is that it isn't the classes (in the narrow sense) that have the magical "no special cases" property, since they are obviously constrained by the nature of their task, but the framework. Any "GEOM proxy" (if we go that route...) will obviously be made usable in any place in the topology. --------------enig489BDBA41EDF048D75E21F0D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknFYFEACgkQldnAQVacBcigAQCfQWfv8DVzp4TwDYh8QLkidN6U l/YAoNAc/pckuWXX5MLcZT0aDUmHPaJf =lZEp -----END PGP SIGNATURE----- --------------enig489BDBA41EDF048D75E21F0D--