From owner-freebsd-geom@FreeBSD.ORG Mon Jul 24 11:03:16 2006 Return-Path: X-Original-To: freebsd-geom@freebsd.org 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 00C5716A514 for ; Mon, 24 Jul 2006 11:03:16 +0000 (UTC) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0ED1643DA4 for ; Mon, 24 Jul 2006 11:02:44 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k6OB2cKi013618 for ; Mon, 24 Jul 2006 11:02:38 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k6OB2bDM013614 for freebsd-geom@freebsd.org; Mon, 24 Jul 2006 11:02:37 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 24 Jul 2006 11:02:37 GMT Message-Id: <200607241102.k6OB2bDM013614@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-geom@FreeBSD.org Cc: Subject: Current problem reports assigned to you 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, 24 Jul 2006 11:03:16 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2005/01/21] kern/76538 geom [gbde] nfs-write on gbde partition stalls o [2005/08/04] kern/84556 geom [geom] GBDE-encrypted swap causes panic a o [2005/10/16] kern/87544 geom [gbde] mmaping large files on a gbde file o [2005/11/16] kern/89102 geom [geom_vfs] [panic] panic when forced unmo o [2005/12/08] bin/90093 geom fdisk(8) incapable of altering in-core ge o [2005/12/18] kern/90582 geom [geom_mirror] [panic] Restore cause panic o [2006/04/15] kern/95771 geom [geom] geom mirror provider destroyed (ma o [2006/05/27] kern/98034 geom [geom] dereference of NULL pointer in acd o [2006/06/09] kern/98742 geom [geli] IO errors while using geli o [2006/06/21] kern/99256 geom [geli] kernel panic/freeze with geli and 10 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2005/02/26] bin/78131 geom gbde "destroy" not working. o [2005/03/26] kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o [2006/03/18] kern/94632 geom [geom] Kernel output resets input while G o [2006/06/05] kern/98538 geom [geom] Kernel panic on ggate destroy 4 problems total. From owner-freebsd-geom@FreeBSD.ORG Tue Jul 25 13:26:59 2006 Return-Path: X-Original-To: freebsd-geom@freebsd.org 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 BEDEB16A4DD for ; Tue, 25 Jul 2006 13:26:59 +0000 (UTC) (envelope-from arne_woerner@yahoo.com) Received: from web30313.mail.mud.yahoo.com (web30313.mail.mud.yahoo.com [68.142.201.231]) by mx1.FreeBSD.org (Postfix) with SMTP id 512FA43D45 for ; Tue, 25 Jul 2006 13:26:59 +0000 (GMT) (envelope-from arne_woerner@yahoo.com) Received: (qmail 35259 invoked by uid 60001); 25 Jul 2006 13:26:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=b8KdgLh0OnVlg38RLerBi+2M+ShR2QZ5NIGYV+v9yy+FyPS+fhR7Ognl3kYI7OS8lv+c56vwtGjvffLOoh1MCetDtmBRRJ9Mew3nRxcExIjdZU/u7SLpVgGdT2Ox6PvpGWlCXvsvD4WmEk1sxFqKv8Y3L+CGkc3GB+u72JZyxtk= ; Message-ID: <20060725132658.35256.qmail@web30313.mail.mud.yahoo.com> Received: from [213.54.65.59] by web30313.mail.mud.yahoo.com via HTTP; Tue, 25 Jul 2006 06:26:58 PDT Date: Tue, 25 Jul 2006 06:26:58 -0700 (PDT) From: "R. B. Riddick" To: freebsd-geom@freebsd.org In-Reply-To: <20060714122936.17967.qmail@web30302.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: new class / geom_raid5 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: Tue, 25 Jul 2006 13:26:59 -0000 --- "R. B. Riddick" wrote: > I solved the deadlock by pretending a lack of memory, so that the request, > that > was to be ->start()'ed is pushed back to the end of the down queue, which > slows > down all requests of every geom (due to pace) a little bit, doesn't it? > Now I put those write requests, that might be in violation of consistency rules, into an own queue, that is flushed, when the conflicting synchronization cycle is over... So now we do not have that artificial delay problem due to the ENOMEM trick... I hope, my assumption that the write requests are executed in the order they are g_io_request'ed, is right... Or isn't it? Is it necessary to wait for the call to ...done() before I order a conflicting g_io_request()? E. g.: If we had a write request A to a dirty area immediately before it is synchronized: Can we be sure, that the synchro-reads already find the data out of request A? Has somebody done some graid5-tests in the meantime? Am I doing something wrong? I mean: Regarding the etiquette of this list or so... -Arne __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-geom@FreeBSD.ORG Tue Jul 25 13:57:59 2006 Return-Path: X-Original-To: freebsd-geom@freebsd.org 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 1D5B816A4DD for ; Tue, 25 Jul 2006 13:57:59 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEE1C43D46 for ; Tue, 25 Jul 2006 13:57:57 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id E220B5138C; Tue, 25 Jul 2006 15:57:53 +0200 (CEST) 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 A795951394; Tue, 25 Jul 2006 15:57:44 +0200 (CEST) Date: Tue, 25 Jul 2006 15:57:24 +0200 From: Pawel Jakub Dawidek To: Lee Dilkie Message-ID: <20060725135724.GD44939@garage.freebsd.pl> References: <44BD6DB9.6010501@dilkie.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GyRA7555PLgSTuth" Content-Disposition: inline In-Reply-To: <44BD6DB9.6010501@dilkie.com> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) 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: freebsd-geom Subject: Re: gconcat - adding additional disks 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: Tue, 25 Jul 2006 13:57:59 -0000 --GyRA7555PLgSTuth Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 18, 2006 at 07:24:41PM -0400, Lee Dilkie wrote: > Hi Folks, >=20 > I'm going to add a third disk to my gconcat array and I've googled the pr= oblem and from what I read it can be as simple as: >=20 > > $ mount > /dev/ad0s1a on / (ufs, local) > devfs on /dev (devfs, local) > /dev/ad0s1d on /usr (ufs, local, soft-updates) > /dev/concat/usr2_concat on /usr2 (ufs, local) >=20 > $ gconcat list > Geom name: usr2_concat > State: UP > Status: Total=3D2, Online=3D2 > Type: AUTOMATIC > ID: 3187483959 > Providers: > 1. Name: concat/usr2_concat > Mediasize: 200059870208 (186G) > Sectorsize: 512 > Mode: r1w1e0 > Consumers: > 1. Name: ad2 > Mediasize: 120034123776 (112G) > Sectorsize: 512 > Mode: r1w1e1 > Start: 0 > End: 120034123264 > 2. Name: ad3 > Mediasize: 80025747456 (75G) > Sectorsize: 512 > Mode: r1w1e1 > Start: 120034123264 > End: 200059870208 > >=20 > > {add new drive */dev/ad1*, reboot} > *{QUESTION? do I need to fdisk or bsdlabel the new drive?}* > $ umount /usr2 > $ gconcat stop usr2_concat > $ gconcat label usr2_concat /dev/ad2 /dev/ad3 /dev/ad1 > $ growfs /dev/concat/usr2_concat > $ mount /usr2 >=20 > >=20 > Would this work? Do I need to fdisk or bsdlabel the new disk or what? I don't see any slices, partitions on your gconcat device, so there is no need for fdisk/bsdlabel. > Any pitfalls to growing my gconcat array this way? It should work (your procedure is correct) as long as growfs(8) works correctly. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --GyRA7555PLgSTuth Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFExiNEForvXbEpPzQRAqyjAJ4zoahA1a+H0lVUdGnAEBU1A6nQOwCggZmA p07YjCZy/3HYqd9tFsfb5VU= =+gGU -----END PGP SIGNATURE----- --GyRA7555PLgSTuth-- From owner-freebsd-geom@FreeBSD.ORG Tue Jul 25 14:32:32 2006 Return-Path: X-Original-To: freebsd-geom@freebsd.org 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 EBE8D16A4EB; Tue, 25 Jul 2006 14:32:31 +0000 (UTC) (envelope-from Lee@Dilkie.com) Received: from smtp.mitel.com (smtp.mitel.com [216.191.234.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB9E543D5D; Tue, 25 Jul 2006 14:32:30 +0000 (GMT) (envelope-from Lee@Dilkie.com) Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id B69FF2002F; Tue, 25 Jul 2006 10:32:29 -0400 (EDT) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23426-01; Tue, 25 Jul 2006 10:32:29 -0400 (EDT) Received: from ottpop01.software.mitel.com (ottpop01.mitel.com [134.199.30.50]) by smtp.mitel.com (Postfix) with ESMTP id 3323D20020; Tue, 25 Jul 2006 10:32:29 -0400 (EDT) Received: from [134.199.48.100] (kannt07b [134.199.48.100]) by ottpop01.software.mitel.com (8.12.10/8.12.10) with ESMTP id k6PEWPkv023503; Tue, 25 Jul 2006 10:32:25 -0400 (EDT) Message-ID: <44C62B7C.6010309@Dilkie.com> Date: Tue, 25 Jul 2006 10:32:28 -0400 From: Lee Dilkie User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <44BD6DB9.6010501@dilkie.com> <20060725135724.GD44939@garage.freebsd.pl> In-Reply-To: <20060725135724.GD44939@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com Cc: freebsd-geom Subject: Re: gconcat - adding additional disks 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: Tue, 25 Jul 2006 14:32:32 -0000 Pawel Jakub Dawidek wrote: > On Tue, Jul 18, 2006 at 07:24:41PM -0400, Lee Dilkie wrote: > >> Hi Folks, >> > >> Any pitfalls to growing my gconcat array this way? >> > > It should work (your procedure is correct) as long as growfs(8) works > correctly. > And it didn't but that I managed to resolve. I'm going to send a report on this tonight so we can all see how it does work (and how growfs can be fixed if you're not running 6.x). -lee From owner-freebsd-geom@FreeBSD.ORG Thu Jul 27 19:06:20 2006 Return-Path: X-Original-To: freebsd-geom@FreeBSD.org 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 CCCE316A4DE; Thu, 27 Jul 2006 19:06:20 +0000 (UTC) (envelope-from rik@inse.ru) Received: from mail.inse.ru (inse.ru [144.206.128.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2EE2F43D70; Thu, 27 Jul 2006 19:06:14 +0000 (GMT) (envelope-from rik@inse.ru) Received: from [127.0.0.1] (www.inse.ru [144.206.128.1]) by mail.inse.ru (Postfix) with ESMTP id C07A933C46; Thu, 27 Jul 2006 23:06:12 +0400 (MSD) Message-ID: <44C91045.8090606@inse.ru> Date: Thu, 27 Jul 2006 23:13:09 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.7.12) Gecko/20060103 ASPLinux/1.7.12-1.5.1.1asp X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: freebsd-geom@FreeBSD.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Poul-Henning Kamp , Pawel Jakub Dawidek Subject: bsdlabel: potential bug and/or question about it 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, 27 Jul 2006 19:06:20 -0000 Hi, I am trying to understand filesystem structure to extract data from half-broken hard drive and I've started to read sources of bsdlabel (if someone know any articles about bsdlabel and/or ufs2 structure please let me know). My question is what for mbroffset and what is it? I have only some surmises about it, but it looks that this code could lead to filesystem corruption. But I hope I am wrong :-) http://cvsup.pt.freebsd.org/cgi-bin/cvsweb/cvsweb.cgi/src/sbin/bsdlabel/bsdlabel.c.diff?r1=1.89&r2=1.90 My train of thought was that in case we have the mbroffset not equal to offset of c (raw) partition we wouldn't substruct mbroffset from all offsets. Lets also assume that this case we meet while we started to edit such slice. We've finished editing and started to write results. In case of write we would add mbroffset unconditionally and thus we get wrong offsets and corrupted partition table. Best regards, rik