From owner-freebsd-geom@FreeBSD.ORG Sun Nov 21 16:00:11 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F85216A4CE; Sun, 21 Nov 2004 16:00:11 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3AAF243EA8; Sun, 21 Nov 2004 16:00:11 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 4C0845311; Sun, 21 Nov 2004 17:00:10 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 2372C530A; Sun, 21 Nov 2004 17:00:00 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id D2785B85E; Sun, 21 Nov 2004 16:59:59 +0100 (CET) To: Suleiman Souhlal References: <20023.1100673074@critter.freebsd.dk> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Sun, 21 Nov 2004 16:59:59 +0100 In-Reply-To: (Suleiman Souhlal's message of "Wed, 17 Nov 2004 06:34:31 -0500") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.64 cc: Poul-Henning Kamp cc: freebsd-geom@FreeBSD.org Subject: Re: Severe gbde problem X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Nov 2004 16:00:11 -0000 Suleiman Souhlal writes: > On Nov 17, 2004, at 1:31 AM, Poul-Henning Kamp wrote: > > Do not put your swap partition over the first 16 sectors of the disk, > > those sectors contain bootcode. > Don't you mean "do not put gbde partitions over the first 16 sectors > of the disk"? No, he means "do not put any partition at all over the first 16 sectors of the disk". DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-geom@FreeBSD.ORG Mon Nov 22 01:01:27 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 038A416A4CE for ; Mon, 22 Nov 2004 01:01:27 +0000 (GMT) Received: from gldis.ca (constans.gldis.ca [66.11.169.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 545E343D5C for ; Mon, 22 Nov 2004 01:01:26 +0000 (GMT) (envelope-from gldisater@gldis.ca) Received: from [IPv6:::1] (localhost [127.0.0.1]) by gldis.ca (8.12.11/8.12.11) with ESMTP id iAM0wqCp085100 for ; Sun, 21 Nov 2004 19:58:52 -0500 (EST) (envelope-from gldisater@gldis.ca) Message-ID: <41A13AAD.1000400@gldis.ca> Date: Sun, 21 Nov 2004 20:02:37 -0500 From: Jeremy Faulkner User-Agent: Mozilla Thunderbird 0.9 (X11/20041114) X-Accept-Language: en-us, en MIME-Version: 1.0 To: geom@freebsd.org X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80rc4/561/Fri Oct 29 06:26:00 2004 clamav-milter version 0.80j on constans.gldis.ca X-Virus-Status: Clean Subject: SWAP and FD X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2004 01:01:27 -0000 I was looking at a jpg created from the kern.geom.confdot output and I was wondering, are swap and fd GEOM-aware, or are they geom's that specifically bridge the gap to swap and the floppy disk driver? http://www.gldis.ca/gldisater/geom.jpg -- Jeremy Faulkner Resume: http://www.gldis.ca/gldisater/resume.html From owner-freebsd-geom@FreeBSD.ORG Tue Nov 23 12:38:46 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC07A16A4CE for ; Tue, 23 Nov 2004 12:38:46 +0000 (GMT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7186643D48 for ; Tue, 23 Nov 2004 12:38:46 +0000 (GMT) (envelope-from list-freebsd-2004@morbius.sent.com) Received: from frontend2.messagingengine.com (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id 5CD8EC3B008 for ; Tue, 23 Nov 2004 07:38:45 -0500 (EST) X-Sasl-enc: 7j53ZbajMEHeqTc9UbUTBg 1101213523 Received: from gumby.localhost (unknown [80.41.56.83]) by frontend2.messagingengine.com (Postfix) with ESMTP id EBEFB56F504 for ; Tue, 23 Nov 2004 07:38:43 -0500 (EST) From: RW To: freebsd-geom@freebsd.org Date: Tue, 23 Nov 2004 12:39:33 +0000 User-Agent: KMail/1.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200411231239.33577.list-freebsd-2004@morbius.sent.com> Subject: gbde: ufs & ffs X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2004 12:38:47 -0000 Why does the gbde section of the Handbook recommend running fsck -p -t ffs, which calls fsck_ffs, when ordinary filesystems are checked with fsck_ufs. According to , ffs runs on top of ufs "providing directory structure information, and a variety of disk access optimizations". Am I correct in thinking that soft-updates protect ffs from inconsistency, so that only a background ufs check is required? Is it possible to background check gbde partitions? If so, can it be done after booting is complete? From owner-freebsd-geom@FreeBSD.ORG Tue Nov 23 12:44:54 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D08D516A4CE for ; Tue, 23 Nov 2004 12:44:54 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3076143D41 for ; Tue, 23 Nov 2004 12:44:54 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id iANCipaC043447; Tue, 23 Nov 2004 13:44:51 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: RW From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 23 Nov 2004 12:39:33 GMT." <200411231239.33577.list-freebsd-2004@morbius.sent.com> Date: Tue, 23 Nov 2004 13:44:51 +0100 Message-ID: <43446.1101213891@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: freebsd-geom@freebsd.org Subject: Re: gbde: ufs & ffs X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2004 12:44:54 -0000 In message <200411231239.33577.list-freebsd-2004@morbius.sent.com>, RW writes: > >Why does the gbde section of the Handbook recommend running fsck -p -t ffs, >which calls fsck_ffs, when ordinary filesystems are checked with fsck_ufs. ufs and ffs are two sides of the same one filesystem. The difference is mainly that ufs _could_ potentially be shared with another filesystem using a different storage policy as well. Therefore, in my opinion, the correct name is FFS. >According to >, ffs runs >on top of ufs "providing directory structure information, and a variety of >disk access optimizations". That is 180 degrees wrong. >Am I correct in thinking that soft-updates >protect ffs from inconsistency, so that only a background ufs check is >required? yes. >Is it possible to background check gbde partitions? If so, can it be done >after booting is complete? yes. -- 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 Tue Nov 23 15:11:11 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7529716A4CE for ; Tue, 23 Nov 2004 15:11:11 +0000 (GMT) Received: from gldis.ca (constans.gldis.ca [66.11.169.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB9B843D58 for ; Tue, 23 Nov 2004 15:11:10 +0000 (GMT) (envelope-from gldisater@gldis.ca) Received: from [IPv6:::1] (localhost [127.0.0.1]) by gldis.ca (8.12.11/8.12.11) with ESMTP id iANF8SUT096093 for ; Tue, 23 Nov 2004 10:08:28 -0500 (EST) (envelope-from gldisater@gldis.ca) Message-ID: <41A35364.6030908@gldis.ca> Date: Tue, 23 Nov 2004 10:12:36 -0500 From: Jeremy Faulkner User-Agent: Mozilla Thunderbird 0.9 (X11/20041114) X-Accept-Language: en-us, en MIME-Version: 1.0 To: geom@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80rc4/561/Fri Oct 29 06:26:00 2004 clamav-milter version 0.80j on constans.gldis.ca X-Virus-Status: Clean Subject: report on GEOM X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2004 15:11:11 -0000 For my English class at college, I am required to write on a new technology or trend. I choose to write about GEOM and I would appreciate any feedback regarding the technical accuracy of my report which is still a work in progress. http://www.gldis.ca/gldisater/TechnicalReport-GEOM.pdf The parts that are highlighted yellow are my notes and will be removed before the final submission. -- Jeremy Faulkner Resume: http://www.gldis.ca/gldisater/resume.html From owner-freebsd-geom@FreeBSD.ORG Tue Nov 23 18:44:19 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE97016A4CE for ; Tue, 23 Nov 2004 18:44:19 +0000 (GMT) Received: from lara.cc.fer.hr (lara.cc.fer.hr [161.53.72.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A09643D5A for ; Tue, 23 Nov 2004 18:44:19 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from [127.0.0.1] (localhost.cc.fer.hr [127.0.0.1]) by lara.cc.fer.hr (8.13.1/8.13.1) with ESMTP id iANIiEQt011855 for ; Tue, 23 Nov 2004 19:44:15 +0100 (CET) (envelope-from ivoras@fer.hr) Message-ID: <41A384FE.1070002@fer.hr> Date: Tue, 23 Nov 2004 19:44:14 +0100 From: Ivan Voras User-Agent: Mozilla Thunderbird 0.9 (X11/20041111) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-geom@freebsd.org X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Subject: Big geom_raid3 problems X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2004 18:44:19 -0000 Im trying to use graid3 in production but I've encountered a big problem: I'm creating raid3 volume from three discs: ad4, ad5, ad6. All is well (and I mean everything - removing, inserting, rebuilding the raid device, using a filesystem on it) until I write BSD disk label on the raid volume (/dev/raid3/geri3). At that time, it seems to write partial labels to each of the data drives (like it should, presumably, since it splits requests), but FreeBSD recognizes it! e.g. /dev/ad4a, /dev/ad4b, etc. This by itself wouldn't be bad, but it seems to confuse the hell out of geom_raid3. Here are the messages that it writes on subsequent boot or loading: GEOM_RAID3: Device geri3 created (id=7). GEOM_RAID3: Device geri3: provider ad4 detected. GEOM_RAID3: Device geri3: provider ad5 detected. GEOM_RAID3: Device geri3: provider ad6 detected. GEOM_RAID3: Device geri3: provider ad4 activated. GEOM_RAID3: Device geri3: provider ad6 activated. GEOM_RAID3: Cannot update metadata on disk ad5 (error=1). GEOM_RAID3: Device geri3: provider ad5 activated. GEOM_RAID3: Device geri3: provider raid3/geri3 launched. GEOM_RAID3: Device geri3: provider ad5 disconnected. GEOM_RAID3: Device geri3: provider ad5 detected. GEOM_RAID3: Device geri3: provider ad5 activated. It's weird and disconcerting. Sometimes, the "cannot update metadata" message appears more than once. Usually that means the raid got completely botched (sometimes the computer hangs shortly afterwards): GEOM_RAID3: Device geri3 created (id=7). GEOM_RAID3: Device geri3: provider ad4 detected. GEOM_RAID3: Device geri3: provider ad5 detected. GEOM_RAID3: Device geri3: provider ad6 detected. GEOM_RAID3: Device geri3: provider ad4 activated. GEOM_RAID3: Device geri3: provider ad6 activated. GEOM_RAID3: Cannot update metadata on disk ad5 (error=1) GEOM_RAID3: Device geri3: provider ad5 activated. GEOM_RAID3: Cannot update metadata on disk ad5 (error=1) GEOM_RAID3: Device geri3: provider raid3/geri3 launched. GEOM_RAID3: Device geri3: provider ad5 diconnected. [hang right before "Mounting root" message should appear (root is on a different drive)] Curiosly, the second case appears only when I create the (ufs2) filesystems in /dev/raid3/geri[a,b,d] partitions. I really need a way to partition the device. I tried fdisk but it wants a physical device (with geometry) to work. Creating raid volume from partitions existing partitions instead of devices seems to confuse it also. This is on 5-STABLE from yesterday. Also, at one time, I accidentally wrote a disklabel to /dev/ad4 instead of the raid volume, and it suceeded, though geom_raid3 detected it and started synching the provider. Shouldn't the devices be locked or something? From owner-freebsd-geom@FreeBSD.ORG Tue Nov 23 19:32:35 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 247CA16A4CE for ; Tue, 23 Nov 2004 19:32:35 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id 685A843D41 for ; Tue, 23 Nov 2004 19:32:34 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 8AE5CAC956; Tue, 23 Nov 2004 20:32:30 +0100 (CET) Date: Tue, 23 Nov 2004 20:32:30 +0100 From: Pawel Jakub Dawidek To: Ivan Voras Message-ID: <20041123193230.GH7232@darkness.comp.waw.pl> References: <41A384FE.1070002@fer.hr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sdJFN6SSISdF2ksn" Content-Disposition: inline In-Reply-To: <41A384FE.1070002@fer.hr> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: freebsd-geom@freebsd.org Subject: Re: Big geom_raid3 problems X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2004 19:32:35 -0000 --sdJFN6SSISdF2ksn Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 23, 2004 at 07:44:14PM +0100, Ivan Voras wrote: +> Im trying to use graid3 in production but I've encountered a big problem: +>=20 +> I'm creating raid3 volume from three discs: ad4, ad5, ad6. All is well= =20 +> (and I mean everything - removing, inserting, rebuilding the raid=20 +> device, using a filesystem on it) until I write BSD disk label on the=20 +> raid volume (/dev/raid3/geri3). At that time, it seems to write partial= =20 +> labels to each of the data drives (like it should, presumably, since it= =20 +> splits requests), but FreeBSD recognizes it! e.g. /dev/ad4a, /dev/ad4b,= =20 +> etc. This by itself wouldn't be bad, but it seems to confuse the hell=20 +> out of geom_raid3. Here are the messages that it writes on subsequent=20 +> boot or loading: [...] This problem has been fixed in HEAD and should be MFCed soon. +> Also, at one time, I accidentally wrote a disklabel to /dev/ad4 instead= =20 +> of the raid volume, and it suceeded, though geom_raid3 detected it and= =20 +> started synching the provider. Shouldn't the devices be locked or someth= ing? If it is not opened, it is not protected. If you create a file system on it and you mount this file system this should not be possible anymore. --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --sdJFN6SSISdF2ksn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBo5BOForvXbEpPzQRAj44AKDsZRTxU0Y4/u54bdpuJ7W7FTZ2UQCbBvNS VGh3kWxcIaMeXLJA7Nplhw8= =Hd6x -----END PGP SIGNATURE----- --sdJFN6SSISdF2ksn-- From owner-freebsd-geom@FreeBSD.ORG Wed Nov 24 08:30:43 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0DAFA16A4CE for ; Wed, 24 Nov 2004 08:30:43 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C84F43D54 for ; Wed, 24 Nov 2004 08:30:42 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id iAO8UfRC061191; Wed, 24 Nov 2004 09:30:41 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Jeremy Faulkner From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 23 Nov 2004 10:12:36 EST." <41A35364.6030908@gldis.ca> Date: Wed, 24 Nov 2004 09:30:41 +0100 Message-ID: <61190.1101285041@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: geom@freebsd.org Subject: Re: report on GEOM X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2004 08:30:43 -0000 In message <41A35364.6030908@gldis.ca>, Jeremy Faulkner writes: >http://www.gldis.ca/gldisater/TechnicalReport-GEOM.pdf first page: s/that the read has/that the reader has/ In general I would refrase everything from "It is also assumed..." to not involve the reader at all, but merely state that we use the following convention: ... second page: 1 "DEVFS " - Rather than the footnote approach I would probably just mark the glossary entries in some (subtle!) way. s/connected to a FreeBSD computer system// You already said that this was FreeBSD. It doesn't run without the computer. "will be different..." You probably need to give an example. "an event queue" Actually there is an event queue for changes to the topology and two I/O queues for pushing data up respectively down. You should explain that the provider is the service point and that a consumer is used to access that service. You will probably want to note that multiple consumers can attach to one provider, but not the other way around. The provider doesn't "give[s] the associated consumers ...". The consumers are not associated but attached, and they request the information out of the provider, it's not the provider pushing the information on the consumers. Also, you list only the mandatory attributes, there are optional attributes handled with the BIO_GETATTR request. Loose all exclamation marks. "The two geoms..." I would loose the rather rambling text from here and instead explain what happens when the system boots: First the diskdriver finds a drive and greates an geom_disk instance "ad0" and gives it a provider. The "tasting" happens and the MBR class finds MBR paritition metadata and decides to ... etc. You probably want to give the stripe-before-mirror vs. mirror-before-stripe example (graphically ?) to show why free stackability is important. -- 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 Wed Nov 24 13:16:08 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED9AE16A4CE for ; Wed, 24 Nov 2004 13:16:08 +0000 (GMT) Received: from postman.arcor.de (postman2.arcor-online.net [151.189.20.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3D0743D1D for ; Wed, 24 Nov 2004 13:16:07 +0000 (GMT) (envelope-from neumannj@arcor.de) Received: from [192.168.128.109] (dsl-082-082-078-097.arcor-ip.net [82.82.78.97]) (authenticated bits=0)iAODG4Ti023793 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 24 Nov 2004 14:16:05 +0100 (MET) Message-ID: <41A48993.6050203@arcor.de> Date: Wed, 24 Nov 2004 14:16:03 +0100 From: Jan-Oliver Neumann User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-geom@freebsd.org Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070603010206060200090808" X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: gvinum: raid5 rebuild hangs on md disk X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2004 13:16:09 -0000 This is a cryptographically signed message in MIME format. --------------ms070603010206060200090808 Content-Type: multipart/mixed; boundary="------------000004080607050909020803" This is a multi-part message in MIME format. --------------000004080607050909020803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, to test gvinum raid5 functionality, I created three file-backed mds and used the following config: drive disk3 device /dev/md2 drive disk2 device /dev/md1 drive disk1 device /dev/md0 volume raid5 plex name raid5.p0 org raid5 546s vol raid5 sd name raid5.p0.s2 drive disk3 len 130494s driveoffset 265s plex raid5.p0 plexoffset 1092s sd name raid5.p0.s1 drive disk2 len 130494s driveoffset 265s plex raid5.p0 plexoffset 546s sd name raid5.p0.s0 drive disk1 len 130494s driveoffset 265s plex raid5.p0 plexoffset 0s The raid5 plex is running fine with this setup and after killing one of the mds using "mdconfig -d -u 0", the raid5 plex is running correctly in degraded mode. When I reattach the md, the "lost" subdisk shows up again as "stale", but when restarting the plex, the rebuild process stalls at 0%, the plex continues to operate in "degraded" mode. Rest of the system is not affected, I am running 5-STABLE as of Nov 24th. ps -axw shows following kernel thread: 621 ?? DL 0:00.02 [gv_rebuild raid5.p0] As a side note, I updated the gvinum help message to reflect the current state of implementation, patch is attached. Regards, Jan-Oliver *** gvinum.c~ Wed Aug 4 02:23:00 2004 --- gvinum.c Wed Nov 24 13:53:15 2004 *************** *** 357,389 **** gvinum_help(void) { printf("COMMANDS\n" ! "attach plex volume [rename]\n" ! "attach subdisk plex [offset] [rename]\n" ! " Attach a plex to a volume, or a subdisk to a plex.\n" ! "checkparity plex [-f] [-v]\n" ! " Check the parity blocks of a RAID-4 or RAID-5 plex.\n" ! "concat [-f] [-n name] [-v] drives\n" ! " Create a concatenated volume from the specified drives.\n" "create [-f] description-file\n" " Create a volume as described in description-file.\n" ! "detach [-f] [plex | subdisk]\n" ! " Detach a plex or subdisk from the volume or plex to" ! "which it is\n" ! " attached.\n" ! "dumpconfig [drive ...]\n" ! " List the configuration information stored on the" ! " specified\n" ! " drives, or all drives in the system if no drive names" ! " are speci-\n" ! " fied.\n" ! "info [-v] [-V]\n" ! " List information about volume manager state.\n" "init [-S size] [-w] plex | subdisk\n" " Initialize the contents of a subdisk or all the subdisks" " of a\n" " plex to all zeros.\n" - "label volume\n" - " Create a volume label.\n" "l | list [-r] [-s] [-v] [-V] [volume | plex | subdisk]\n" " List information about specified objects.\n" "ld [-r] [-s] [-v] [-V] [volume]\n" --- 357,372 ---- gvinum_help(void) { printf("COMMANDS\n" ! "cancelinit\n" ! " Cancel pending initialization processes.\n" "create [-f] description-file\n" " Create a volume as described in description-file.\n" ! "help\n" ! " Print this help message.\n" "init [-S size] [-w] plex | subdisk\n" " Initialize the contents of a subdisk or all the subdisks" " of a\n" " plex to all zeros.\n" "l | list [-r] [-s] [-v] [-V] [volume | plex | subdisk]\n" " List information about specified objects.\n" "ld [-r] [-s] [-v] [-V] [volume]\n" *************** *** 394,431 **** " List information about plexes.\n" "lv [-r] [-s] [-v] [-V] [volume]\n" " List information about volumes.\n" - "mirror [-f] [-n name] [-s] [-v] drives\n" - " Create a mirrored volume from the specified drives.\n" - "move | mv -f drive object ...\n" - " Move the object(s) to the specified drive.\n" "printconfig [file]\n" " Write a copy of the current configuration to file.\n" "quit Exit the vinum program when running in interactive mode." " Nor-\n" " mally this would be done by entering the EOF character.\n" - "rename [-r] [drive | subdisk | plex | volume] newname\n" - " Change the name of the specified object.\n" - "rebuildparity plex [-f] [-v] [-V]\n" - " Rebuild the parity blocks of a RAID-4 or RAID-5 plex.\n" - "resetconfig\n" - " Reset the complete vinum configuration.\n" "rm [-f] [-r] volume | plex | subdisk\n" " Remove an object.\n" "saveconfig\n" " Save vinum configuration to disk after configuration" " failures.\n" - "setstate state [volume | plex | subdisk | drive]\n" - " Set state without influencing other objects, for" - " diagnostic pur-\n" - " poses only.\n" "start [-i interval] [-S size] [-w] volume | plex | subdisk\n" " Allow the system to access the objects.\n" "stop [-f] [volume | plex | subdisk]\n" " Terminate access to the objects, or stop vinum if no" " parameters\n" " are specified.\n" - "stripe [-f] [-n name] [-v] drives\n" - " Create a striped volume from the specified drives.\n" ); return; --- 377,398 ---- --------------000004080607050909020803-- --------------ms070603010206060200090808 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6TCC As8wggI4oAMCAQICAw0p/TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQxMDA0MTUxMjI2WhcNMDUxMDA0MTUxMjI2 WjBDMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSAwHgYJKoZIhvcNAQkBFhFu ZXVtYW5uakBhcmNvci5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALRJ6aRs ymv+Msef0dhbRWinlzgjF0xoao8IQno2Ij7QMwM1bHdTSviIdMOWEut6TWlE+SwceQh8qSj1 OTyRve0Ef3tWCq6SiUlb5Hlnp2aD4bJR0JvKw74JKb78Db7SA9Ihe8B4TMG3DPpxUtJCI4At e7yVJA8YwBOm353vDEM8ZpiAf51n73/T3vYGrX8NJxX+pbBoE4bvM7YFLLzpI442ep38VYaq GVyFVtPsfSEoIkmVEprYx2g6yvXVxUOy0+3B/sWexAy3GaUlAVOhLCMe4Gcz65mOfVPXluKw OHvkTavfj0/Z2bkcUgGs/W+mI9TQEp/06A/kYwlPxoJrTI8CAwEAAaMuMCwwHAYDVR0RBBUw E4ERbmV1bWFubmpAYXJjb3IuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCo SBwVjpnSLkXMtARjEh2ohIFEkIyo3/deklcI/nmSGHVxc6A7yAMG/h4Fvc22m9UbpWieXXoR SLXRWQu7LkToM9RxgmoY8ZZbI+wijtKZCkUDV+PyUbbKcOicAG5ZP/kE1d+MYxhU5XO0347k WmAfMDP9E+HBRhK71sw4mUB2aTCCAs8wggI4oAMCAQICAw0p/TANBgkqhkiG9w0BAQQFADBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQxMDA0 MTUxMjI2WhcNMDUxMDA0MTUxMjI2WjBDMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVt YmVyMSAwHgYJKoZIhvcNAQkBFhFuZXVtYW5uakBhcmNvci5kZTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALRJ6aRsymv+Msef0dhbRWinlzgjF0xoao8IQno2Ij7QMwM1bHdT SviIdMOWEut6TWlE+SwceQh8qSj1OTyRve0Ef3tWCq6SiUlb5Hlnp2aD4bJR0JvKw74JKb78 Db7SA9Ihe8B4TMG3DPpxUtJCI4Ate7yVJA8YwBOm353vDEM8ZpiAf51n73/T3vYGrX8NJxX+ pbBoE4bvM7YFLLzpI442ep38VYaqGVyFVtPsfSEoIkmVEprYx2g6yvXVxUOy0+3B/sWexAy3 GaUlAVOhLCMe4Gcz65mOfVPXluKwOHvkTavfj0/Z2bkcUgGs/W+mI9TQEp/06A/kYwlPxoJr TI8CAwEAAaMuMCwwHAYDVR0RBBUwE4ERbmV1bWFubmpAYXJjb3IuZGUwDAYDVR0TAQH/BAIw ADANBgkqhkiG9w0BAQQFAAOBgQCoSBwVjpnSLkXMtARjEh2ohIFEkIyo3/deklcI/nmSGHVx c6A7yAMG/h4Fvc22m9UbpWieXXoRSLXRWQu7LkToM9RxgmoY8ZZbI+wijtKZCkUDV+PyUbbK cOicAG5ZP/kE1d+MYxhU5XO0347kWmAfMDP9E+HBRhK71sw4mUB2aTCCAz8wggKooAMCAQIC AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B 1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1 3iSx0x1G/11fZU8xggM7MIIDNwIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIDDSn9MAkGBSsOAwIaBQCgggGnMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MTEyNDEzMTYwM1owIwYJKoZIhvcNAQkEMRYE FMTn3WSH/GmsewjkMBeduf9cSsILMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMHgG CSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMNKf0wegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDSn9MA0GCSqGSIb3DQEBAQUABIIBAIIZXGcMMTcK /Q4A11v+iBOgES3wZCasj8s92QeCvJligPEorBf26Yb97wTL5/5NuWO1cQvDj1RSGGmMVmVY GkATUjEpEw6KSzGenr7OucoyLVP7g4d8AO7feEdlQp/k5rIArxQA/ENrRAGrvI+XwSsH0FQ1 gi/TO5KzVT9yKQKAhgtv+Okp8ty4eq9ZbOnLURHeDvVQtZh/MSJlA52iz8/ecnUpyheRbMlM +YigvvOt+eirpzwY+mktjcdDgA4iuX9ZlFfI2+uBfzK5zZxlkXS163U9/iehkCW8BtUwayJ3 /K2y4CAnzypxIQHQBQYcm4gzUKogv+KQNN2KJmq/ORQAAAAAAAA= --------------ms070603010206060200090808-- From owner-freebsd-geom@FreeBSD.ORG Wed Nov 24 13:28:59 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9EB516A4CE for ; Wed, 24 Nov 2004 13:28:59 +0000 (GMT) Received: from imap.univie.ac.at (mail.univie.ac.at [131.130.1.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3ED7D43D41 for ; Wed, 24 Nov 2004 13:28:59 +0000 (GMT) (envelope-from le@FreeBSD.org) Received: from pcle2.cc.univie.ac.at (pcle2.cc.univie.ac.at [131.130.2.177]) by imap.univie.ac.at (8.12.10/8.12.10) with ESMTP id iAODSnAB089234; Wed, 24 Nov 2004 14:28:51 +0100 Date: Wed, 24 Nov 2004 14:28:49 +0100 (CET) From: Lukas Ertl To: Jan-Oliver Neumann In-Reply-To: <41A48993.6050203@arcor.de> Message-ID: <20041124142643.I96527@pcle2.cc.univie.ac.at> References: <41A48993.6050203@arcor.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-DCC-ZID-Univie-Metrics: mx7.univie.ac.at 4248; Body=2 Fuz1=2 Fuz2=2 cc: freebsd-geom@FreeBSD.org Subject: Re: gvinum: raid5 rebuild hangs on md disk X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2004 13:29:00 -0000 On Wed, 24 Nov 2004, Jan-Oliver Neumann wrote: > The raid5 plex is running fine with this setup and after killing one of > the mds using "mdconfig -d -u 0", the raid5 plex is running correctly in > degraded mode. When I reattach the md, the "lost" subdisk shows up again > as "stale", but when restarting the plex, the rebuild process stalls at > 0%, the plex continues to operate in "degraded" mode. Rest of the system > is not affected, I am running 5-STABLE as of Nov 24th. Hmmm, it seems the threads blocks somewhere. I need to investigate this further. I guess it should be able to rebuild fine after a reboot, but this is an md device it's not really useful. :-) Thanks for the report. cheers, le -- Lukas Ertl http://homepage.univie.ac.at/l.ertl/ le@FreeBSD.org http://people.freebsd.org/~le/ From owner-freebsd-geom@FreeBSD.ORG Wed Nov 24 23:48:53 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 213DB16A4CE; Wed, 24 Nov 2004 23:48:53 +0000 (GMT) Received: from blackwater.lemis.com (wantadilla.lemis.com [192.109.197.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 788E043D1D; Wed, 24 Nov 2004 23:48:51 +0000 (GMT) (envelope-from grog@lemis.com) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 29DF38564E; Thu, 25 Nov 2004 10:18:48 +1030 (CST) Date: Thu, 25 Nov 2004 10:18:48 +1030 From: Greg 'groggy' Lehey To: Lukas Ertl Message-ID: <20041124234848.GI43681@wantadilla.lemis.com> References: <41A48993.6050203@arcor.de> <20041124142643.I96527@pcle2.cc.univie.ac.at> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ahst0DKxuyFxAqHk" Content-Disposition: inline In-Reply-To: <20041124142643.I96527@pcle2.cc.univie.ac.at> User-Agent: Mutt/1.4.2.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 cc: freebsd-geom@FreeBSD.org cc: Jan-Oliver Neumann Subject: Re: gvinum: raid5 rebuild hangs on md disk X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2004 23:48:53 -0000 --Ahst0DKxuyFxAqHk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wednesday, 24 November 2004 at 14:28:49 +0100, Lukas Ertl wrote: > On Wed, 24 Nov 2004, Jan-Oliver Neumann wrote: > >> The raid5 plex is running fine with this setup and after killing one of >> the mds using "mdconfig -d -u 0", the raid5 plex is running correctly in >> degraded mode. When I reattach the md, the "lost" subdisk shows up again >> as "stale", but when restarting the plex, the rebuild process stalls at >> 0%, the plex continues to operate in "degraded" mode. Rest of the system >> is not affected, I am running 5-STABLE as of Nov 24th. > > Hmmm, it seems the threads blocks somewhere. I need to investigate this > further. I guess it should be able to rebuild fine after a reboot, but > this is an md device it's not really useful. :-) Without a backtrace, there's little you can do one way or another. Greg -- See complete headers for address and phone numbers. --Ahst0DKxuyFxAqHk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBpR3gIubykFB6QiMRAuOtAJ0Xh7zKWVtAbaq46/pQhbaKXt/iQACcD/mc PDeKYfIexo+vGvWeZ0BusLM= =wh+g -----END PGP SIGNATURE----- --Ahst0DKxuyFxAqHk--