From owner-freebsd-geom@FreeBSD.ORG Sun Apr 8 00:16:58 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8F8F616A403 for ; Sun, 8 Apr 2007 00:16:58 +0000 (UTC) (envelope-from fbsd06@mlists.homeunix.com) Received: from turtle-out.mxes.net (turtle-out.mxes.net [216.86.168.191]) by mx1.freebsd.org (Postfix) with ESMTP id 693D213C44B for ; Sun, 8 Apr 2007 00:16:58 +0000 (UTC) (envelope-from fbsd06@mlists.homeunix.com) Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by turtle-in.mxes.net (Postfix) with ESMTP id 9A4701050E for ; Sat, 7 Apr 2007 19:59:46 -0400 (EDT) Received: from gumby.homeunix.com (unknown [87.81.140.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id F36A451939 for ; Sat, 7 Apr 2007 19:59:44 -0400 (EDT) Date: Sun, 8 Apr 2007 00:59:42 +0100 From: RW To: freebsd-geom@freebsd.org Message-ID: <20070408005942.48c10ea8@gumby.homeunix.com> X-Mailer: Claws Mail 2.8.1 (GTK+ 2.10.11; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Geli Encrypted DVDs X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2007 00:16:58 -0000 In the questions list Roland Smith suggested that a geli encrypted dvd could be created by burning the backing file from an geli encrypted md device as a disk image. We were neither able to attach the DVD device though, see: http://lists.freebsd.org/pipermail/freebsd-questions/2007-March/145433.html Does anyone know if this can be made to work? FWIW I have no problem putting a UFS2 filesystem on a DVD-R without geli. From owner-freebsd-geom@FreeBSD.ORG Sun Apr 8 00:32:59 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A944116A403 for ; Sun, 8 Apr 2007 00:32: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 2CA5A13C44B for ; Sun, 8 Apr 2007 00:32:58 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 83FA8487F2; Sun, 8 Apr 2007 02:32:56 +0200 (CEST) Received: from localhost (cvl74.internetdsl.tpnet.pl [83.19.93.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id A116A456B1; Sun, 8 Apr 2007 02:32:46 +0200 (CEST) Date: Sun, 8 Apr 2007 02:32:33 +0200 From: Pawel Jakub Dawidek To: RW Message-ID: <20070408003233.GT63916@garage.freebsd.pl> References: <20070408005942.48c10ea8@gumby.homeunix.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="udzYTtuEmHLUHegf" Content-Disposition: inline In-Reply-To: <20070408005942.48c10ea8@gumby.homeunix.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=-2.5 required=3.0 tests=BAYES_00,RCVD_IN_NJABL_DUL autolearn=no version=3.0.4 Cc: freebsd-geom@freebsd.org Subject: Re: Geli Encrypted DVDs X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2007 00:32:59 -0000 --udzYTtuEmHLUHegf Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 08, 2007 at 12:59:42AM +0100, RW wrote: >=20 > In the questions list Roland Smith suggested that a geli encrypted dvd > could be created by burning the backing file from an geli encrypted md > device as a disk image.=20 >=20 > We were neither able to attach the DVD device though, see: >=20 > http://lists.freebsd.org/pipermail/freebsd-questions/2007-March/145433.ht= ml >=20 > Does anyone know if this can be made to work? >=20 > FWIW I have no problem putting a UFS2 filesystem on a DVD-R without > geli. Could you give me the output of: # ls -l $HOME/backupDVD.img=20 # diskinfo -v /dev/acd0 # geli dump /dev/acd0 --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --udzYTtuEmHLUHegf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGGDghForvXbEpPzQRAkA5AJ46OSYYU7YpYBv/E5SXSvZHxM/czQCg9IJX yBEgb/Lg+6gA3lhBrmKLYgY= =9nVG -----END PGP SIGNATURE----- --udzYTtuEmHLUHegf-- From owner-freebsd-geom@FreeBSD.ORG Sun Apr 8 02:31:21 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 458F016A402 for ; Sun, 8 Apr 2007 02:31:21 +0000 (UTC) (envelope-from fbsd06@mlists.homeunix.com) Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by mx1.freebsd.org (Postfix) with ESMTP id 1FE3713C484 for ; Sun, 8 Apr 2007 02:31:19 +0000 (UTC) (envelope-from fbsd06@mlists.homeunix.com) Received: from gumby.homeunix.com (unknown [87.81.140.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id B6CCC5194D for ; Sat, 7 Apr 2007 22:31:17 -0400 (EDT) Date: Sun, 8 Apr 2007 03:31:14 +0100 From: RW To: freebsd-geom@freebsd.org Message-ID: <20070408033114.128f7da8@gumby.homeunix.com> In-Reply-To: <20070408003233.GT63916@garage.freebsd.pl> References: <20070408005942.48c10ea8@gumby.homeunix.com> <20070408003233.GT63916@garage.freebsd.pl> X-Mailer: Claws Mail 2.8.1 (GTK+ 2.10.11; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Geli Encrypted DVDs X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2007 02:31:21 -0000 On Sun, 8 Apr 2007 02:32:33 +0200 Pawel Jakub Dawidek wrote: > On Sun, Apr 08, 2007 at 12:59:42AM +0100, RW wrote: > > > > In the questions list Roland Smith suggested that a geli encrypted > > dvd could be created by burning the backing file from an geli > > encrypted md device as a disk image. > > > > We were neither able to attach the DVD device though, see: > > > > http://lists.freebsd.org/pipermail/freebsd-questions/2007-March/145433.html > > > > Does anyone know if this can be made to work? > > > > FWIW I have no problem putting a UFS2 filesystem on a DVD-R without > > geli. > > Could you give me the output of: > > # ls -l $HOME/backupDVD.img > # diskinfo -v /dev/acd0 > # geli dump /dev/acd0 > # ls -l /home/t/dvd.img -rw-r--r-- 1 bob bob 4613734400 Mar 21 13:15 /home/t/dvd.img # diskinfo -v /dev/acd0 /dev/acd0 2048 # sectorsize 4613734400 # mediasize in bytes (4.3G) 2252800 # mediasize in sectors # geli dump /dev/acd0 Cannot read metadata from /dev/acd0: Invalid argument. Not fully done. ------------------------------------------------- If I run the last command on the image file's md device instead: # geli dump /dev/md0 Metadata on /dev/md0: magic: GEOM::ELI version: 3 flags: 0x0 ealgo: AES-CBC keylen: 256 provsize: 4613734400 sectorsize: 512 keys: 0x01 iterations: 61292 Salt: bdf68c63c63839100061f7bca0dbf6351065119f0679945dc13b53b418e739ff73492a158f300a165df449f37d6b4359efb21b6f5201fcf2fc6acf1af29850b1 Master Key: 9f8eaf77c0183b09dca50be0d25a15979aec2cf02dc53870f0b55bcdd911b663fcbfeab0a5567fe7da89ea88a7068a5ab30806b966734e385c43a47cc074156638fca0dc41c3bc27ca8cc52ff5ffac837d8bc116f9a434b2dbf6c520ed5fc1b14ece00e9972b3b1062491db16aa40486ce05c1969b642b9436cbfab472ba581a9600e4390b27913bca1b8e74b9a2c610e162948f947d4c14c657968cd1f712f66fd3352ba3a92454a4b190c289a338698273a85fe934db31d8e5d700afee430b4589fa642882caea6509762f63de82be69f9af78c05b73f4419a523ee6ac8b18340cb3bc5491e3d7b17b5682f515f44d00044db05e23f451720348b1a3c0669875f0cd3784269786c32c4b4e501a612bbbb7dbc68ea54e9c6049d402129f9535a1e20b0d1e15b590144f9eacac28f65a04713e2f8fe335dc33e0887a12af8d9740855cbf4e9e42b0ea36532940d0d466f2c5b95e6f04a4ccf296df5ad09f768682b97b9a92733f0a40c85f86509af309e4e52108ada13c484a089516a3249252 MD5 hash: c491b5d6c87206b6e6d3783dde568fb7 From owner-freebsd-geom@FreeBSD.ORG Sun Apr 8 02:35:19 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E83D216A400 for ; Sun, 8 Apr 2007 02:35:18 +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 57C5113C455 for ; Sun, 8 Apr 2007 02:35:17 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 91000487F5; Sun, 8 Apr 2007 04:35:14 +0200 (CEST) Received: from localhost (cvl74.internetdsl.tpnet.pl [83.19.93.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 198904569A; Sun, 8 Apr 2007 04:35:02 +0200 (CEST) Date: Sun, 8 Apr 2007 04:34:50 +0200 From: Pawel Jakub Dawidek To: RW Message-ID: <20070408023450.GV63916@garage.freebsd.pl> References: <20070408005942.48c10ea8@gumby.homeunix.com> <20070408003233.GT63916@garage.freebsd.pl> <20070408033114.128f7da8@gumby.homeunix.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="reSNjdE3Iylkp4B8" Content-Disposition: inline In-Reply-To: <20070408033114.128f7da8@gumby.homeunix.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=-2.5 required=3.0 tests=BAYES_00,RCVD_IN_NJABL_DUL autolearn=no version=3.0.4 Cc: freebsd-geom@freebsd.org Subject: Re: Geli Encrypted DVDs X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2007 02:35:19 -0000 --reSNjdE3Iylkp4B8 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 08, 2007 at 03:31:14AM +0100, RW wrote: > On Sun, 8 Apr 2007 02:32:33 +0200 > Pawel Jakub Dawidek wrote: >=20 > > On Sun, Apr 08, 2007 at 12:59:42AM +0100, RW wrote: > > >=20 > > > In the questions list Roland Smith suggested that a geli encrypted > > > dvd could be created by burning the backing file from an geli > > > encrypted md device as a disk image.=20 > > >=20 > > > We were neither able to attach the DVD device though, see: > > >=20 > > > http://lists.freebsd.org/pipermail/freebsd-questions/2007-March/14543= 3.html > > >=20 > > > Does anyone know if this can be made to work? > > >=20 > > > FWIW I have no problem putting a UFS2 filesystem on a DVD-R without > > > geli. > >=20 > > Could you give me the output of: > >=20 > > # ls -l $HOME/backupDVD.img=20 > > # diskinfo -v /dev/acd0 > > # geli dump /dev/acd0 > >=20 >=20 >=20 > # ls -l /home/t/dvd.img > -rw-r--r-- 1 bob bob 4613734400 Mar 21 13:15 /home/t/dvd.img >=20 > # diskinfo -v /dev/acd0 > /dev/acd0 > 2048 # sectorsize > 4613734400 # mediasize in bytes (4.3G) > 2252800 # mediasize in sectors >=20 > # geli dump /dev/acd0 > Cannot read metadata from /dev/acd0: Invalid argument. > Not fully done. >=20 > ------------------------------------------------- >=20 > If I run the last command on the image file's md device instead: >=20 > # geli dump /dev/md0 > Metadata on /dev/md0: > magic: GEOM::ELI > version: 3 > flags: 0x0 > ealgo: AES-CBC > keylen: 256 > provsize: 4613734400 > sectorsize: 512 The problem is different size between CD and your image. Try to create image with -S 2048 option. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --reSNjdE3Iylkp4B8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGGFTKForvXbEpPzQRAphXAKDr3z+FHHwC6muCUodG0ch62zrzKgCdGeZh krwLp3nv42KzCXzRvzZWZnU= =bdhK -----END PGP SIGNATURE----- --reSNjdE3Iylkp4B8-- From owner-freebsd-geom@FreeBSD.ORG Sun Apr 8 12:27:36 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 58EDD16A400 for ; Sun, 8 Apr 2007 12:27:36 +0000 (UTC) (envelope-from fbsd06@mlists.homeunix.com) Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by mx1.freebsd.org (Postfix) with ESMTP id 31ACD13C484 for ; Sun, 8 Apr 2007 12:27:36 +0000 (UTC) (envelope-from fbsd06@mlists.homeunix.com) Received: from gumby.homeunix.com (unknown [87.81.140.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id D4AAE5193D for ; Sun, 8 Apr 2007 08:27:34 -0400 (EDT) Date: Sun, 8 Apr 2007 13:27:31 +0100 From: RW To: freebsd-geom@freebsd.org Message-ID: <20070408132731.442d1d39@gumby.homeunix.com> In-Reply-To: <20070408023450.GV63916@garage.freebsd.pl> References: <20070408005942.48c10ea8@gumby.homeunix.com> <20070408003233.GT63916@garage.freebsd.pl> <20070408033114.128f7da8@gumby.homeunix.com> <20070408023450.GV63916@garage.freebsd.pl> X-Mailer: Claws Mail 2.8.1 (GTK+ 2.10.11; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Geli Encrypted DVDs X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2007 12:27:36 -0000 On Sun, 8 Apr 2007 04:34:50 +0200 Pawel Jakub Dawidek wrote: > On Sun, Apr 08, 2007 at 03:31:14AM +0100, RW wrote: > > On Sun, 8 Apr 2007 02:32:33 +0200 > > Pawel Jakub Dawidek wrote: > > > > > On Sun, Apr 08, 2007 at 12:59:42AM +0100, RW wrote: > > > > > > > > In the questions list Roland Smith suggested that a geli > > > > encrypted dvd could be created by burning the backing file from > > > > an geli encrypted md device as a disk image. > > > > > > > > We were neither able to attach the DVD device though, see: > > > > > > > > http://lists.freebsd.org/pipermail/freebsd-questions/2007-March/145433.html > > > > > > > > Does anyone know if this can be made to work? > > > > > > > > FWIW I have no problem putting a UFS2 filesystem on a DVD-R > > > > without geli. > > > > > > Could you give me the output of: > > > > > > # ls -l $HOME/backupDVD.img > > > # diskinfo -v /dev/acd0 > > > # geli dump /dev/acd0 > > > > > > > > > # ls -l /home/t/dvd.img > > -rw-r--r-- 1 bob bob 4613734400 Mar 21 13:15 /home/t/dvd.img > > > > # diskinfo -v /dev/acd0 > > /dev/acd0 > > 2048 # sectorsize > > 4613734400 # mediasize in bytes (4.3G) > > 2252800 # mediasize in sectors > > > > # geli dump /dev/acd0 > > Cannot read metadata from /dev/acd0: Invalid argument. > > Not fully done. > > > > ------------------------------------------------- > > > > If I run the last command on the image file's md device instead: > > > > # geli dump /dev/md0 > > Metadata on /dev/md0: > > magic: GEOM::ELI > > version: 3 > > flags: 0x0 > > ealgo: AES-CBC > > keylen: 256 > > provsize: 4613734400 > > sectorsize: 512 > > The problem is different size between CD and your image. Try to create > image with -S 2048 option. > Thanks, that worked. For the benefit of anyone trying this, the -S 2048 option is to mdconfig. If you just use geli init -s 2048 without setting the sector size in mdconfig, the dvd device fails to attach. mdconfig(8) is a bit misleading when it defines: "-S sectorsize Sectorsize to use for malloc backed device." From owner-freebsd-geom@FreeBSD.ORG Sun Apr 8 14:33:36 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5CF2516A402 for ; Sun, 8 Apr 2007 14:33:36 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) by mx1.freebsd.org (Postfix) with ESMTP id 18EB113C468 for ; Sun, 8 Apr 2007 14:33:36 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from localhost (marvin-mail [192.168.0.2]) by marvin.harmless.hu (Postfix) with ESMTP id 7F9167C007B for ; Sun, 8 Apr 2007 16:02:16 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.4.2 (20060627) (Debian) at harmless.hu Received: from marvin.harmless.hu ([192.168.0.2]) by localhost (marvin.harmless.hu [192.168.0.2]) (amavisd-new, port 10024) with ESMTP id ewlqjDNNoL-c for ; Sun, 8 Apr 2007 16:02:16 +0200 (CEST) Received: from marvin.harmless.hu (localhost [127.0.0.1]) by marvin.harmless.hu (Postfix) with ESMTP id 351377BFEBF for ; Sun, 8 Apr 2007 16:02:15 +0200 (CEST) Date: Sun, 8 Apr 2007 16:02:15 +0200 From: Gergely CZUCZY To: freebsd-geom@freebsd.org Message-ID: <20070408140215.GA54201@harmless.hu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline User-Agent: mutt-ng/devel-r804 (FreeBSD) Subject: volume management X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2007 14:33:36 -0000 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, I'm looking for a disk organization, volume-management feature in freebsd, something like LVM-like in a kind of way. Currently on our linux boxes we are using LVM to organize the disks under our content-drives. This means, we allocate a we-think-it-will-be-enough space for a service from a storage pool for each service on the actual box, and if later on the givenm space turns out not to be enough, we increase that amount and grow the FS on it. I'm looking for a similar feature in FreeBSD, where i can allocate disk space for my proposes, not using up all of the available space, and later on be able to increase the size of any previously allocated "chunk". First i've tried gvinum on a 6.2-STABLE box, but as i found out it cannot do the job. Or it was just that underdocumented that i wasn't able to do it with gvinum My question is, where should i start looking for a feature like this? Bye, Gergely Czuczy mailto: gergely.czuczy@harmless.hu --=20 Weenies test. Geniuses solve problems that arise. --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) owFtVD1sVEcQdiA0iyjcpUIjJHDB7Yt9gIWNwGAbO4mMUtgCJKp97829t9y+3WN/ zj6LispIIEWOIkWJpSB6JCJBQUVDTUVHQwcdoqCiYXbvziBEc7rdnfnm+76ZeX8c OThxYPLl4yc3Tt7b/feHRz/u5Seb4L2ueCNsX2o+Mz09w8+cbtPvKX5azJyaLmeL dvvM2fbc3NzKTx/fLhntUXu+MejhPHjc8j/3lJD6HBS1sA79+eA7/Cwbxy1L1zNO emn0PEitpMb9tw0rtOug5Zd1YUqpq3m4FYzHkves1F7kChn7BZUyLcZ+nWpAGdOl MOgYCwJK6bpgbCW03BaxQAv6RoUGSYwWFTZUg3VQ+GCRSkPHIuaubIEzDfo6AinZ RVi7eoWnPxQjgAqUYDqwKQYZWwrWEooagNFggqUEHbYgN1voYBNBEHJwEYlAwJsx HWS+xkTQQdAl2pRcjHSXVvbRZbBRSwcNkgmtBEZCC+GRCTrxSLDLpeebUimeI0dt QlWD64kCRw44pKbFkzVNPHpjSTfrGaNSBIqi3g8iBZGUKHwQKkpogSCpsgOKitrR O6uIm25GZcg67Yi7B2181JcjDHkkxlIXFoWjuFp4EI0J5HgErazZTNVW1iOu9Nl3 +udkI5Ww8FWLVqhFi+vLBF5jvIFC6C++pIZ/0d8MoGcNTReSf5HfsBOhFzNiC5Pc vqAiNEnDxFaity+Y5KQ3UvaVFoqlFkYEoWMN7EsTnBqwMZMSjhV10N1jGVuR1nmQ U31KtJJeKlqj0ERwAbNZm69vXFpcuzz0OycjhSNZHXKqTL5Kz0hjZF+aVPqmyTP4 3dIDjaCDm4Hgk71pjkpThDjXVChdyhikp8j1kQxCiZnS1yMmjF0Z0FqhixsC0o29 dbUJitpPUyOs/6Y145aktaBJdAuMLQ7IPbaKtkLah6XtUGwPWEPuejMP1fA6K9L1 RfoUNAqdy+rAGOfn29PsGqKWtDWemGSwSodAjaNdVGQd9ZH4N240SFY6zNjOwsFD E/GbM/5gTR7I3kw8+P/6hZ2/n356/tuJu//cv7OwW+UPL078t/z+2YfDR1/tftz7 8/bai3f2r9njrz8D =EtCx -----END PGP SIGNATURE----- --nFreZHaLTZJo0R7j-- From owner-freebsd-geom@FreeBSD.ORG Sun Apr 8 14:38:10 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AF88C16A406 for ; Sun, 8 Apr 2007 14:38:10 +0000 (UTC) (envelope-from news@nermal.rz1.convenimus.net) Received: from mailr3.de.ignite.net (mailr3.de.ignite.net [62.134.11.18]) by mx1.freebsd.org (Postfix) with ESMTP id 283C513C4AD for ; Sun, 8 Apr 2007 14:38:09 +0000 (UTC) (envelope-from news@nermal.rz1.convenimus.net) Received: from nermal.rz1.convenimus.net (c-134-176-43.d.dsl.de.ignite.net [62.134.176.43]) by mailr3.de.ignite.net (Switch-3.1.9/Switch-3.1.7) with SMTP id l38Ec7sQ018400 for ; Sun, 8 Apr 2007 16:38:08 +0200 (MEST) Received: by nermal.rz1.convenimus.net (Postfix, from userid 8) id 02EB815213; Sun, 8 Apr 2007 16:38:06 +0200 (CEST) To: freebsd-geom@freebsd.org Path: not-for-mail From: Christian Baer Newsgroups: gmane.os.freebsd.devel.geom Date: Sun, 8 Apr 2007 16:38:06 +0200 (CEST) Organization: Convenimus Projekt Lines: 9 Message-ID: NNTP-Posting-Host: garfield.rz1.convenimus.net X-Trace: nermal.rz1.convenimus.net 1176043086 17456 192.168.100.11 (8 Apr 2007 14:38:06 GMT) X-Complaints-To: abuse@convenimus.net NNTP-Posting-Date: Sun, 8 Apr 2007 14:38:06 +0000 (UTC) User-Agent: slrn/0.9.8.1 (FreeBSD) Subject: geli on DVD-RAM X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2007 14:38:10 -0000 Hi again! This isn't really an urgent matter, but will become interesting for me quite soon. Can I encrypt the contents of a DVD-RAM directly with geli, thus creating an encrypted filesystem on the disc directly? Basicly, can I create a /dev/acd0.eli? Regards Chris From owner-freebsd-geom@FreeBSD.ORG Sun Apr 8 14:49:49 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C25CF16A400 for ; Sun, 8 Apr 2007 14:49:49 +0000 (UTC) (envelope-from news@nermal.rz1.convenimus.net) Received: from mailr1.de.ignite.net (mailr1.de.ignite.net [195.182.110.146]) by mx1.freebsd.org (Postfix) with ESMTP id 43B1713C46E for ; Sun, 8 Apr 2007 14:49:48 +0000 (UTC) (envelope-from news@nermal.rz1.convenimus.net) Received: from nermal.rz1.convenimus.net (c-134-176-43.d.dsl.de.ignite.net [62.134.176.43]) by mailr1.de.ignite.net (Switch-3.1.9/Switch-3.1.7) with ESMTP id l38Enlvu017897 for ; Sun, 8 Apr 2007 16:49:47 +0200 (MEST) Received: by nermal.rz1.convenimus.net (Postfix, from userid 8) id C902A15213; Sun, 8 Apr 2007 16:49:46 +0200 (CEST) To: freebsd-geom@freebsd.org Path: not-for-mail From: Christian Baer Newsgroups: gmane.os.freebsd.devel.geom Date: Sun, 8 Apr 2007 16:49:46 +0200 (CEST) Organization: Convenimus Projekt Lines: 14 Message-ID: NNTP-Posting-Host: garfield.rz1.convenimus.net X-Trace: nermal.rz1.convenimus.net 1176043786 17456 192.168.100.11 (8 Apr 2007 14:49:46 GMT) X-Complaints-To: abuse@convenimus.net NNTP-Posting-Date: Sun, 8 Apr 2007 14:49:46 +0000 (UTC) User-Agent: slrn/0.9.8.1 (FreeBSD) Subject: geli and LRW-mode X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2007 14:49:49 -0000 Hi once again! Since I am sitting around and working with geli anyway, I thought I might ask this question too. :-) Are there any plans to make geli work in LRW-mode, possibly only as an alternative to CBC? Now I haven't done any studies into the depths of these two modes but I have read about both. As I understand it, LRW is the mode that was made especially for encrypted file systems. Regards Chris From owner-freebsd-geom@FreeBSD.ORG Sun Apr 8 16:32:31 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0E50F16A406 for ; Sun, 8 Apr 2007 16:32:31 +0000 (UTC) (envelope-from fbsd06@mlists.homeunix.com) Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by mx1.freebsd.org (Postfix) with ESMTP id DD39613C48A for ; Sun, 8 Apr 2007 16:32:30 +0000 (UTC) (envelope-from fbsd06@mlists.homeunix.com) Received: from gumby.homeunix.com (unknown [87.81.140.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id C209B5191A for ; Sun, 8 Apr 2007 12:32:29 -0400 (EDT) Date: Sun, 8 Apr 2007 17:32:27 +0100 From: RW To: freebsd-geom@freebsd.org Message-ID: <20070408173227.7798594e@gumby.homeunix.com> In-Reply-To: References: X-Mailer: Claws Mail 2.8.1 (GTK+ 2.10.11; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: geli on DVD-RAM X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2007 16:32:31 -0000 On Sun, 8 Apr 2007 16:38:06 +0200 (CEST) Christian Baer wrote: > Hi again! > > This isn't really an urgent matter, but will become interesting for me > quite soon. Can I encrypt the contents of a DVD-RAM directly with > geli, thus creating an encrypted filesystem on the disc directly? > Basicly, can I create a /dev/acd0.eli? It should be pretty straightforward given that, according to section 17.7.9 of the handbook, it can be disklabeled and newfs'ed like hard disk.Why not just try it? You might also be interested in the thread above. about geli on a DVD-/+R. From owner-freebsd-geom@FreeBSD.ORG Sun Apr 8 18:14:19 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EA70716A4D4 for ; Sun, 8 Apr 2007 18:14:19 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id AD30913C483 for ; Sun, 8 Apr 2007 18:14:19 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 41D9320A1; Sun, 8 Apr 2007 20:14:16 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id B4A9B2090; Sun, 8 Apr 2007 20:14:15 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id A0165A10A5; Sun, 8 Apr 2007 20:14:15 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Gergely CZUCZY References: <20070408140215.GA54201@harmless.hu> Date: Sun, 08 Apr 2007 20:14:15 +0200 In-Reply-To: <20070408140215.GA54201@harmless.hu> (Gergely CZUCZY's message of "Sun, 8 Apr 2007 16:02:15 +0200") Message-ID: <86k5wmu420.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-geom@freebsd.org Subject: Re: volume management X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2007 18:14:20 -0000 Gergely CZUCZY writes: > I'm looking for a disk organization, volume-management feature in > freebsd, something like LVM-like in a kind of way. Currently on our > linux boxes we are using LVM to organize the disks under our > content-drives. This means, we allocate a we-think-it-will-be-enough > space for a service from a storage pool for each service on the > actual box, and if later on the givenm space turns out not to be > enough, we increase that amount and grow the FS on it. ZFS in -CURRENT does that and more. I also have unfinished code for a GEOM-based LVM, but none of FreeBSD's file systems support on-the-fly resizing, so ZFS is really your best option. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-geom@FreeBSD.ORG Sun Apr 8 18:19:19 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 287BF16A401 for ; Sun, 8 Apr 2007 18:19:19 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) by mx1.freebsd.org (Postfix) with ESMTP id A598613C489 for ; Sun, 8 Apr 2007 18:19:18 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from localhost (marvin-mail [192.168.0.2]) by marvin.harmless.hu (Postfix) with ESMTP id 89E237C0BAE; Sun, 8 Apr 2007 20:19:17 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.4.2 (20060627) (Debian) at harmless.hu Received: from marvin.harmless.hu ([192.168.0.2]) by localhost (marvin.harmless.hu [192.168.0.2]) (amavisd-new, port 10024) with ESMTP id BTC5-vm4rIxA; Sun, 8 Apr 2007 20:19:17 +0200 (CEST) Received: from marvin.harmless.hu (localhost [127.0.0.1]) by marvin.harmless.hu (Postfix) with ESMTP id 302207C0B87; Sun, 8 Apr 2007 20:19:16 +0200 (CEST) Date: Sun, 8 Apr 2007 20:19:16 +0200 From: Gergely CZUCZY To: Dag-Erling =?utf-8?B?U23DuHJncmF2?= Message-ID: <20070408181916.GA59715@harmless.hu> References: <20070408140215.GA54201@harmless.hu> <86k5wmu420.fsf@dwp.des.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline In-Reply-To: <86k5wmu420.fsf@dwp.des.no> User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: freebsd-geom@freebsd.org Subject: Re: volume management X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2007 18:19:19 -0000 --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 08, 2007 at 08:14:15PM +0200, Dag-Erling Sm=C3=B8rgrav wrote: > Gergely CZUCZY writes: > > I'm looking for a disk organization, volume-management feature in > > freebsd, something like LVM-like in a kind of way. Currently on our > > linux boxes we are using LVM to organize the disks under our > > content-drives. This means, we allocate a we-think-it-will-be-enough > > space for a service from a storage pool for each service on the > > actual box, and if later on the givenm space turns out not to be > > enough, we increase that amount and grow the FS on it. >=20 > ZFS in -CURRENT does that and more. I also have unfinished code for a > GEOM-based LVM, but none of FreeBSD's file systems support on-the-fly > resizing, so ZFS is really your best option. yeap, i know about ZFS, as i assume, it will need around 1.5-2 years =66rom now, when 7.0-RELEASE will be ready. and with that i'm not sure ZFS will be a stable feature, for no it's experimental. and i'm looking for a solution for a production environment within a year. on-the-fly growfs is not required. stopping the service for a few minutes can be done, since we've got enough redundancy in our server farm. and UFS2 has growfs(8), that would be enough. > > DES cool signo :) Bye, Gergely Czuczy mailto: gergely.czuczy@harmless.hu --=20 Weenies test. Geniuses solve problems that arise. --EeQfGwPcQSOJBaQU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) owFlVTFvHEUUNolIMRGIiALRvQLJhOwsd5fY51xiQ3y+QxExAZ8NwlSzu293R96d 2czM3nldpaRACCEKpAgJUQBNJJAQNRUd/AFExS+gChINb3bvDBLdztzM9773fd+b ++SZi2sXrvz63Q8fXPvo00dPPb70XPRKWTunMl4KM5eK93u9Pt+4Oexv8A0+HOAw FcP+zV6SXt+Mpi8OXhpr5VA5fthUOAKHp+7VqhBS3YI4F8ai265dyrfY6tyetJW2 0kmtRiBVIRWe/3ZohLIpGj5RsU6kykbwoNYOE14ZqZyICmTsvoJZrQK4UxnobQUw 6PWGIBx9j/o3Rv2Nt/fhWo82A9gTGZ8YqpDBrNweX9/e3TKZEXNYGAIdsR14A02G RQPj46Px8ftwu8o1lvL0dWJeFmhtmNc7dFo6tP74DtxdL6HQ+sRjptqAgETaE9Am E0qeCd9VAHNd1CWSgEpkWFJjkKJwtUHqt0VJDWJkkwCsLtHlHqyQJwj33t3n7YdU hExFEtApLEQTAoxrYwiKyGoFujYtEPVWn0KkT9HCAkFQidp6OEICp1e8EFyOLVML tUrQnAPES+UTI+doQzjMpYUSyYagBSwKHQtHH7TinukJl44vZFHwCDkqXWd5C2Qr EeNSEouUHL8yuvRLpw0JAZXWRXsCRZyfH6JuiFyLIWJXi8K3E4Cg3mUKBRU3yzOQ EUdVLkuRnspSHw6Udr7XqAPpOLXspYoNCuu7p3yIUtdkhQfOjF60iNOZx5YuZDvb gx7dP6YdEp+Pjw4OJm8dQqJJ2e463Su1QbLiLuliNeRiTnKrVCppc0xIy2SpgE/W 5P4+j6h44r0IIGqJKvSGTsn+3dneuoVUFgi2sQ5LC7auKm0cMSKlkadFQzgGrTwj R31WOnaW9siXBhoykbq2dKPywQtZg6IKQMKJov5E5MWhKySmpU1hLaWSfnbg/QOF xE0YEiWBfrjBB0DXjWXbm5veN4IgEXNUMAx7/GByb3JnNuluRugpJJRKL8pCuryT SK6XrRmWos4819VpnwE/vKs5CFqZlCYuJAKeVmiknxNRhKw1/n9TZmmkfI/LZWV0 UsftBqq5NFq1Y+ap0IiJtpOQ/Stk63hqvXieoMEHtTSYhD6bVeXL+DSc57atkeKC lTRfNPsQC+X7SMhAMoJyhZSvdbI/I7QucQSakJRCxY1PkB8wj0fpTekx6fo6ms4G FBu7pPPy1tWgU26h6yLxFTqskLEd8n5vMmOxHxorMxJrdJUxtttgwNj5u3VWx2cN K4UsnB5B1m2Hcbv931eMMc59wt9DVNJHmmIT0vOnZG1pSfJSM6QqmVSuAm+kxZB9 +NrFp9f8Q7/6k7hy4eF07Yvnf5tU33z8/eM/bjz5/Ou1N3+/dEt+tvblo2cHl7/d ffj3T3/9+Ocv77zwRP781fQf =m+W0 -----END PGP SIGNATURE----- --EeQfGwPcQSOJBaQU-- From owner-freebsd-geom@FreeBSD.ORG Sun Apr 8 18:57:26 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A4AEC16A401 for ; Sun, 8 Apr 2007 18:57:26 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 671B213C46E for ; Sun, 8 Apr 2007 18:57:26 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id C502F2091; Sun, 8 Apr 2007 20:57:22 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 4680E2090; Sun, 8 Apr 2007 20:57:22 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id 312A4A10AC; Sun, 8 Apr 2007 20:57:22 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Gergely CZUCZY References: <20070408140215.GA54201@harmless.hu> <86k5wmu420.fsf@dwp.des.no> <20070408181916.GA59715@harmless.hu> Date: Sun, 08 Apr 2007 20:57:22 +0200 In-Reply-To: <20070408181916.GA59715@harmless.hu> (Gergely CZUCZY's message of "Sun, 8 Apr 2007 20:19:16 +0200") Message-ID: <86bqhyu225.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-geom@freebsd.org Subject: Re: volume management X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2007 18:57:26 -0000 Gergely CZUCZY writes: > yeap, i know about ZFS, as i assume, it will need around 1.5-2 years > from now, when 7.0-RELEASE will be ready. No, it's expected this fall. > and i'm looking for a solution for a production environment within > a year. There is no other solution. > on-the-fly growfs is not required. stopping the service for a few > minutes can be done, since we've got enough redundancy in our > server farm. > and UFS2 has growfs(8), that would be enough. I suspect growfs(8) may take more than a few minutes... DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-geom@FreeBSD.ORG Sun Apr 8 19:23:22 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 93BC916A403 for ; Sun, 8 Apr 2007 19:23:22 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) by mx1.freebsd.org (Postfix) with ESMTP id 4EB8E13C45B for ; Sun, 8 Apr 2007 19:23:22 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from localhost (marvin-mail [192.168.0.2]) by marvin.harmless.hu (Postfix) with ESMTP id 33A1D7BFCDD; Sun, 8 Apr 2007 21:23:21 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.4.2 (20060627) (Debian) at harmless.hu Received: from marvin.harmless.hu ([192.168.0.2]) by localhost (marvin.harmless.hu [192.168.0.2]) (amavisd-new, port 10024) with ESMTP id lO0jkQduZ68e; Sun, 8 Apr 2007 21:23:21 +0200 (CEST) Received: from marvin.harmless.hu (localhost [127.0.0.1]) by marvin.harmless.hu (Postfix) with ESMTP id CE0897BFCDC; Sun, 8 Apr 2007 21:23:20 +0200 (CEST) Date: Sun, 8 Apr 2007 21:23:20 +0200 From: Gergely CZUCZY To: Dag-Erling =?utf-8?B?U23DuHJncmF2?= Message-ID: <20070408192320.GA61233@harmless.hu> References: <20070408140215.GA54201@harmless.hu> <86k5wmu420.fsf@dwp.des.no> <20070408181916.GA59715@harmless.hu> <86bqhyu225.fsf@dwp.des.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline In-Reply-To: <86bqhyu225.fsf@dwp.des.no> User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: freebsd-geom@freebsd.org Subject: Re: volume management X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2007 19:23:22 -0000 --AqsLC8rIMeq19msA Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 08, 2007 at 08:57:22PM +0200, Dag-Erling Sm=C3=B8rgrav wrote: > Gergely CZUCZY writes: > > yeap, i know about ZFS, as i assume, it will need around 1.5-2 years > > from now, when 7.0-RELEASE will be ready. >=20 > No, it's expected this fall. 6.2-R was also expected around late-october. release processes are always late, and even a this kind of a major release will need many fixes i think. > > and i'm looking for a solution for a production environment within > > a year. > There is no other solution. >=20 > > on-the-fly growfs is not required. stopping the service for a few > > minutes can be done, since we've got enough redundancy in our > > server farm. > > and UFS2 has growfs(8), that would be enough. >=20 > I suspect growfs(8) may take more than a few minutes... doesn't really matters... anyways, thank very much for your response. Bye, Gergely Czuczy mailto: gergely.czuczy@harmless.hu --=20 Weenies test. Geniuses solve problems that arise. --AqsLC8rIMeq19msA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) owFNVD2PHEUQPX8QMBKBhQQioiLO1u0Mu3Pau/XCLdyd9ywkPr1nIY6od6ZmttmZ 6nF/7Nw4wZFNYBkLQkv+B5YIyAgdkZAg8QeI+AWICKpn7vbIprvqvXr1qnqevnZl 4/K13376+eutxz88u/Ti6qP5VumspTwshV5JCgf9/iDcGcTb2+EwHIzw5s5wkMbD WMzTeH701v71Q0UWyYbHTYVjsHhq360KIek9SBZCG7R7zmbhKDjPuyVNpYy0UtEY JBWScB071oJMhjqcUqJSSfkY7jllMQ0rLcmKeYFB8BnBzFEP9isN/VEP4n5/F4Tl 7/FwdxzHn38CW32+7MEtkYdTzRVymJV7h9t7ByOda7GCWjPpOJjAbdQ5Fg0cntw9 PPkK3q8WCkt5+iErLws0Jlq4CWdLi8anT6BBUfVAwpJUDWKunIWTo1kPhOFLYYwr kcMWalkUQIgpCK0cpTCIhmHs4dq0RJlWJTBJD+oFEuxG/fDO9OPp/mzaYecIGkXa RMFkL+4z5FPliTcN4GmFCXsCdiENZKIoomAnisM7ULMKURh1kXJWvBAWQ5VYNUcd BRoLFAah0irhHpFBGhlYi8a0qdwOg3DFukRXZSkpDVTGx1J8ozScU1y0WQpqIJOn 6I1gDC2joG3UU8nNEgqlln4SGcMFGFU4vwJnR5aSuqS9QFpJrajkfWB6z9TRtN6x G3C8QJbLokiBsnxYk/mKnVkTUBRyLMx4uLlWdWY6hGXp95zUmEZgrKoqL4kTwSCv e4JnejKsW5ZSkuPZQyLITyRVxOYYSZxY4+YKIWdGJOXyBROn7LWgpOG1BuV0y+B5 WWLGCxWt/bh7NIthwdPqpF0f3eixCN7hWrki9ZU6zvXwPwLjjJ/pBYIdb8CKJUKp 2A+GUyf8XHQURUGq0NCmb5rXpGGItajbSMDz8gNvC9MSWCTHXbJoHWhYPoP4pZJB Tj5osBcE69dy3yX3m6AUsrBqDHl3HSXt9f/fThCEoW/gS0SSbCOrshE/OpLOrx3P bdWuIb/r0nQOCC19xe8+uPLKhv+9nP+brl3+d7rxvPf9m0+Pvnhy+8e//nz95S/f DuODtx9uPL/x9+NXl7+/8es/z4z549GLlw/euWr/Aw== =I+xu -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- From owner-freebsd-geom@FreeBSD.ORG Sun Apr 8 19:47:03 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 536D116A401 for ; Sun, 8 Apr 2007 19:47:03 +0000 (UTC) (envelope-from news@nermal.rz1.convenimus.net) Received: from mailr2.de.ignite.net (mailr2.de.ignite.net [195.182.110.148]) by mx1.freebsd.org (Postfix) with ESMTP id DCD7713C458 for ; Sun, 8 Apr 2007 19:47:02 +0000 (UTC) (envelope-from news@nermal.rz1.convenimus.net) Received: from mailr1.de.ignite.net (mailr1.de.ignite.net [195.182.110.146]) by mailr2.de.ignite.net (Switch-3.1.9/Switch-3.1.7) with ESMTP id l38EOx6r014866 for ; Sun, 8 Apr 2007 16:24:59 +0200 (MEST) Received: from nermal.rz1.convenimus.net (c-134-176-43.d.dsl.de.ignite.net [62.134.176.43]) by mailr1.de.ignite.net (Switch-3.1.9/Switch-3.1.7) with ESMTP id l38EOtd6010857 for ; Sun, 8 Apr 2007 16:24:56 +0200 (MEST) Received: by nermal.rz1.convenimus.net (Postfix, from userid 8) id A69FB15213; Sun, 8 Apr 2007 16:24:54 +0200 (CEST) To: freebsd-geom@freebsd.org Path: not-for-mail From: Christian Baer Newsgroups: gmane.os.freebsd.devel.geom Date: Sun, 8 Apr 2007 16:24:54 +0200 (CEST) Organization: Convenimus Projekt Lines: 28 Message-ID: NNTP-Posting-Host: garfield.rz1.convenimus.net X-Trace: nermal.rz1.convenimus.net 1176042294 17456 192.168.100.11 (8 Apr 2007 14:24:54 GMT) X-Complaints-To: abuse@convenimus.net NNTP-Posting-Date: Sun, 8 Apr 2007 14:24:54 +0000 (UTC) User-Agent: slrn/0.9.8.1 (FreeBSD) Subject: gmirror and geli integrity check X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2007 19:47:03 -0000 Hi peeps! A while ago I set up a Sun U60 with two filesystems, that were mirrored and then encrypted with geli with data integrity check on (init -a). This was done in exactly *that* order (first the mirror, then geli). Now I am having second thoughts about this altogether... The reason is that the combination of these two functions is to protect information from other people and from loss through hardware failure. I did the init with -a so that I could easily *find* broken data. I am not concerned that this machine will be somehow manipulated so that I need to find out if someone has been tampering with my data. This was for protection against lost though a hardware problem alone. What happens if one drive breaks down or has a broken sector? Will this combination help me to save data or to detect the broken sector? Or will it cause more problems than it could solve? The reason for my worries is the fact that the mirror was created first. If one filesystem was created first and this filesystem were mirrored (in doing so, forcing both filesystems to be encrypted seperately), the integrity check would work for both filesystems and thus for both drives. A broken file system could be identified easily. But what happens if one of the drives in the mirror is broken? Would I be able to identify the broken one? Regards and happy Easter! Chris From owner-freebsd-geom@FreeBSD.ORG Mon Apr 9 11:10:15 2007 Return-Path: X-Original-To: freebsd-geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AF20016A402 for ; Mon, 9 Apr 2007 11:10:15 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 9FF8213C4AD for ; Mon, 9 Apr 2007 11:10:15 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l39BAFTM057387 for ; Mon, 9 Apr 2007 11:10:15 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l39BAAab057133 for freebsd-geom@FreeBSD.org; Mon, 9 Apr 2007 11:10:10 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 9 Apr 2007 11:10:10 GMT Message-Id: <200704091110.l39BAAab057133@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon 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, 09 Apr 2007 11:10:15 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/73177 geom kldload geom_* causes panic due to memory exhaustion o kern/76538 geom [gbde] nfs-write on gbde partition stalls and continue o kern/83464 geom [geom] [patch] Unhandled malloc failures within libgeo o kern/84556 geom [geom] GBDE-encrypted swap causes panic at shutdown o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o kern/89102 geom [geom_vfs] [panic] panic when forced unmount FS from u o bin/90093 geom fdisk(8) incapable of altering in-core geometry o kern/90582 geom [geom_mirror] [panic] Restore cause panic string (ffs_ o kern/98034 geom [geom] dereference of NULL pointer in acd_geom_detach o kern/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML 10 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/78131 geom gbde "destroy" not working. o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/94632 geom [geom] Kernel output resets input while GELI asks for f kern/105390 geom [geli] filesystem on a md backed by sparse file with s o kern/107707 geom [geom] [patch] add new class geom_xbox360 to slice up p bin/110705 geom gmirror control utility does not exit with correct exi 6 problems total. From owner-freebsd-geom@FreeBSD.ORG Mon Apr 9 14:28:43 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 969F116A402 for ; Mon, 9 Apr 2007 14:28:43 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id 6D00213C469 for ; Mon, 9 Apr 2007 14:28:43 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l39ESZQQ039769; Mon, 9 Apr 2007 09:28:38 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <461A4D93.3010200@freebsd.org> Date: Mon, 09 Apr 2007 09:28:35 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.10 (X11/20070320) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <20070408140215.GA54201@harmless.hu> <86k5wmu420.fsf@dwp.des.no> <20070408181916.GA59715@harmless.hu> <86bqhyu225.fsf@dwp.des.no> In-Reply-To: <86bqhyu225.fsf@dwp.des.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.88.4/3052/Mon Apr 9 07:23:53 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: Gergely CZUCZY , freebsd-geom@freebsd.org Subject: Re: volume management 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, 09 Apr 2007 14:28:43 -0000 On 04/08/07 13:57, Dag-Erling Smørgrav wrote: > Gergely CZUCZY writes: >> yeap, i know about ZFS, as i assume, it will need around 1.5-2 years >> from now, when 7.0-RELEASE will be ready. > > No, it's expected this fall. > >> and i'm looking for a solution for a production environment within >> a year. > > There is no other solution. How about gconcat? You could create a mirror, then gconcat another mirror, etc, extending the GEOM. Then run growfs on that extended volume. Wouldn't that work? >> on-the-fly growfs is not required. stopping the service for a few >> minutes can be done, since we've got enough redundancy in our >> server farm. >> and UFS2 has growfs(8), that would be enough. > > I suspect growfs(8) may take more than a few minutes... > > DES From owner-freebsd-geom@FreeBSD.ORG Mon Apr 9 14:29:51 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0095A16A404 for ; Mon, 9 Apr 2007 14:29:51 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id CBF0313C480 for ; Mon, 9 Apr 2007 14:29:50 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l39ETmmj039957; Mon, 9 Apr 2007 09:29:48 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <461A4DDC.2090307@freebsd.org> Date: Mon, 09 Apr 2007 09:29:48 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.10 (X11/20070320) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <20070408140215.GA54201@harmless.hu> <86k5wmu420.fsf@dwp.des.no> In-Reply-To: <86k5wmu420.fsf@dwp.des.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.88.4/3052/Mon Apr 9 07:23:53 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: Gergely CZUCZY , freebsd-geom@freebsd.org Subject: Re: volume management 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, 09 Apr 2007 14:29:51 -0000 On 04/08/07 13:14, Dag-Erling Smørgrav wrote: > Gergely CZUCZY writes: >> I'm looking for a disk organization, volume-management feature in >> freebsd, something like LVM-like in a kind of way. Currently on our >> linux boxes we are using LVM to organize the disks under our >> content-drives. This means, we allocate a we-think-it-will-be-enough >> space for a service from a storage pool for each service on the >> actual box, and if later on the givenm space turns out not to be >> enough, we increase that amount and grow the FS on it. > > ZFS in -CURRENT does that and more. I also have unfinished code for a > GEOM-based LVM, but none of FreeBSD's file systems support on-the-fly > resizing, so ZFS is really your best option. Is that code available in P4 somewhere (or elsewhere)? Sounds interesting. Eric From owner-freebsd-geom@FreeBSD.ORG Mon Apr 9 14:38:21 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 24F0E16A400 for ; Mon, 9 Apr 2007 14:38:21 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) by mx1.freebsd.org (Postfix) with ESMTP id 9EF1413C487 for ; Mon, 9 Apr 2007 14:38:20 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from localhost (marvin-mail [192.168.0.2]) by marvin.harmless.hu (Postfix) with ESMTP id 871787BFF53; Mon, 9 Apr 2007 16:38:19 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.4.2 (20060627) (Debian) at harmless.hu Received: from marvin.harmless.hu ([192.168.0.2]) by localhost (marvin.harmless.hu [192.168.0.2]) (amavisd-new, port 10024) with ESMTP id H4bd7AJYXGeo; Mon, 9 Apr 2007 16:38:19 +0200 (CEST) Received: from marvin.harmless.hu (localhost [127.0.0.1]) by marvin.harmless.hu (Postfix) with ESMTP id 155ED7BFCDF; Mon, 9 Apr 2007 16:38:18 +0200 (CEST) Date: Mon, 9 Apr 2007 16:38:18 +0200 From: Gergely CZUCZY To: Eric Anderson Message-ID: <20070409143818.GA86722@harmless.hu> References: <20070408140215.GA54201@harmless.hu> <86k5wmu420.fsf@dwp.des.no> <20070408181916.GA59715@harmless.hu> <86bqhyu225.fsf@dwp.des.no> <461A4D93.3010200@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="HcAYCG3uE/tztfnV" Content-Disposition: inline In-Reply-To: <461A4D93.3010200@freebsd.org> User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: freebsd-geom@freebsd.org Subject: Re: volume management 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, 09 Apr 2007 14:38:21 -0000 --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 09, 2007 at 09:28:35AM -0500, Eric Anderson wrote: > On 04/08/07 13:57, Dag-Erling Sm=C3=B8rgrav wrote: > >Gergely CZUCZY writes: > >>yeap, i know about ZFS, as i assume, it will need around 1.5-2 years > >>from now, when 7.0-RELEASE will be ready. > >No, it's expected this fall. > >>and i'm looking for a solution for a production environment within > >>a year. > >There is no other solution. >=20 > How about gconcat? You could create a mirror, then gconcat another mirro= r, etc, extending the GEOM.=20 > Then run growfs on that extended volume. Wouldn't that work? why gmirror? gconcat somehow could be used for this, but 1) i see no attach operation for gconcat to add providers on the fly. 2) this would require to always create subpartitions/bsdlabels on the disk, and add a bit more on need. like the following example: - there are 4 filesystems by default: fs1,fs2,fs3,fs4 - given da0s1g the "reminder" of the disks, that will give the space needed for the services. we allocate 4 labels for the services: da0s1ga, da0s2gd, da0s2ge, da0s2gf - we concat the four bsdlabels, to be able to later on enlarge them. now increasing the size would look like ( _IF_ gconcat would support it): - creating a new bsdlabel, that would serve as the incrementum, like we add da0s2gg NOTE: we reach "h" we cannot add more, bsdlables are limited. we would have to recursively bsdlabel all the last bsdlabels to have te ability to chop another piece that could be added later on. - attaching the new partition to the already existing concat - growing the filesystem all of this looks like a PITA to me. like we would need a spoon, and all we have is a hammer, so we start eating our soup with the hammer... i have the definite feeling that gconcat serves a whole different propose. Bye, Gergely Czuczy mailto: gergely.czuczy@harmless.hu --=20 Weenies test. Geniuses solve problems that arise. --HcAYCG3uE/tztfnV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) owFVVkGLHEUUXhOE0CAS8KQIj73EkO7ZntlddzNmN242kxg0WXE3hCSHWNP9errY 6qpOVfXMTi7izYOI5OBFBP+A4MGLFw+CoAjevMSrB8FLvHj2veqZTjz00F3v1Xtf fe97r+bzl06vnDr727ff3b/w6eMvX/jmzMVxXDXe60lSCTuVOumnaT/ZfnNrMEj6 G0k/S7cxF+m66G9cpN9rrx482Tfao/bJ0bzGIXg88Wu1ElK/BVkprEO/0/gi2Y6W flelq42TXho9BKmV1NjZjqzQrkCbjHRmcqknQ3jYGI95UlupvRgrjKIDDTeNjmGv tpBejGGQplsgPL0PB9vD9c29m5Ckm2kaw8jKDPZ0jtYZDTNLkYbRLlCAdGMt3V6j ff314eZWDFfFJBlZwjKBw2pnf33nyradWDF9tmn3OtoJqjns37u9f+8uXKpLg5U8 eZsOWSl0rlc2u+QuPbrgvztHUccg4VibGYixaTzcu3YYg3C0KJxrKiSzh5lUCjRi DsKaRufQ720mA6Dt1oVAhTUVUJAYZiVq2OqlyQej90Z7h6N27xjBosjnPfa+ZTjo OQd4UmNG1IEvpYNCKBXsu4IyyHMVKGOO+byFsSDAGdVwSRaftTV5k4UF1FNpja6o PpSOguk2TAAYQh6VaBEoiTZgPH100ci8M0jJ552OgklmdCb8ZYC7poHMNCqHjOB7 pLSVtNbYmCDTOReeIHQbNBh3IjKjz+jnhCTDGmFvuD46uNlrc8ER77YNRbBmVjig Q/iSArU7iJEpwauwB3CH0+tzvrXPjD2+HM3KOUxaIJc7DM5UWNIZWrxEeOMoDnPF 7MbRuPFR/zzV1SEyDcJ7kZVgarSio3UZzJM9zyPieCpZmy1AhEJRCQfn24LNQiaL DxtJ5PIWNRNzt+TKNeNaWB/ayK2NXa7EGJWLFqFy6Y5JaVRqykTEjklnlaFAZGep 9aJIyWNs0xqlzIyJxBNR1YrkDglbyF3QswGFJIHPncfKwXgOORaiUX4IhevHhRvQ s07PBm+byCmRTyPC9dvCrFrqEm7BVTBFh83FC8pZv7wnCiZXiwwDwI5dWkSaRBm6 HswIEGHNmACC1R6Z/aL/OQ4X+UUcXgaTfPmCy5eCsVK4ZUUCDY2FjsiYKac688jh V0U5LYR2UIIGAW+piEXubam5KG4pRScf4aJ83GMQiH4DHty49qCTQGt2TV0b66lf zwfOQ205jCAOZh2YJVftHjok8gzhVCEzd2ZTxSFPFDiikrfHnERw6+BoNORVik2K XC1Xw7mFpq4KniyLeJGLyhxKrmRFcywPjIe0EZRiGoiwmDXWUcVoFC4BclUCHiWc f8Yhu7fbmEeppJ9HvJaVpu66upaYYXvArrkIFtV/SXmPqWkbakkxs9PJn0PyolBh CpKKpQsstlwHVdpW4KHOnZijiHEHVVLDca1cWywB79842uO4PCXC0pKIIM6I5mVt +A4KHUZByBxOSnEEvVUV0phyhtedJ6CwKCxpLHKmqcMkDXBa516PtCQXbHGPYCE1 lQAKRNUiF/7ZNGINcKZZaRQ3VEF3JqmARwrdrUixrswxjqLuznrUZI/mUSWk8mYI k3a5l4Xl52+wKEoSnqJ3ELWkFHSZ+R5cpw8aeI7nOgGkLKSUyrWghJWc8ZPd0y+u 8P+B5b+Js6fOXFj54tKPP3/45N212z+98uvvj5/+89H9739Z+fqzHz4+Wb/075/y r9eevn649vcfw5e/+g8= =RWB3 -----END PGP SIGNATURE----- --HcAYCG3uE/tztfnV-- From owner-freebsd-geom@FreeBSD.ORG Mon Apr 9 15:13:23 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3D12A16A526 for ; Mon, 9 Apr 2007 15:13:23 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id 12C7D13C4B9 for ; Mon, 9 Apr 2007 15:13:22 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l39FDM2x047914; Mon, 9 Apr 2007 10:13:22 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <461A5812.1080205@freebsd.org> Date: Mon, 09 Apr 2007 10:13:22 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.10 (X11/20070320) MIME-Version: 1.0 To: Gergely CZUCZY References: <20070408140215.GA54201@harmless.hu> <86k5wmu420.fsf@dwp.des.no> <20070408181916.GA59715@harmless.hu> <86bqhyu225.fsf@dwp.des.no> <461A4D93.3010200@freebsd.org> <20070409143818.GA86722@harmless.hu> In-Reply-To: <20070409143818.GA86722@harmless.hu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.88.4/3052/Mon Apr 9 07:23:53 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: freebsd-geom@freebsd.org Subject: Re: volume management 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, 09 Apr 2007 15:13:23 -0000 On 04/09/07 09:38, Gergely CZUCZY wrote: > On Mon, Apr 09, 2007 at 09:28:35AM -0500, Eric Anderson wrote: >> On 04/08/07 13:57, Dag-Erling SmÞrgrav wrote: >>> Gergely CZUCZY writes: >>>> yeap, i know about ZFS, as i assume, it will need around 1.5-2 years >>> >from now, when 7.0-RELEASE will be ready. >>> No, it's expected this fall. >>>> and i'm looking for a solution for a production environment within >>>> a year. >>> There is no other solution. >> How about gconcat? You could create a mirror, then gconcat another mirror, etc, extending the GEOM. >> Then run growfs on that extended volume. Wouldn't that work? > why gmirror? gconcat somehow could be used for this, > but > 1) i see no attach operation for gconcat to add > providers on the fly. > 2) this would require to always create subpartitions/bsdlabels > on the disk, and add a bit more on need. > > like the following example: > - there are 4 filesystems by default: fs1,fs2,fs3,fs4 > - given da0s1g the "reminder" of the disks, that will give > the space needed for the services. we allocate 4 labels for > the services: da0s1ga, da0s2gd, da0s2ge, da0s2gf > - we concat the four bsdlabels, to be able to later on enlarge them. > > now increasing the size would look like ( _IF_ gconcat would support it): > - creating a new bsdlabel, that would serve as the incrementum, like > we add da0s2gg > NOTE: we reach "h" we cannot add more, bsdlables are limited. we would > have to recursively bsdlabel all the last bsdlabels to have te ability > to chop another piece that could be added later on. > - attaching the new partition to the already existing concat > - growing the filesystem > > all of this looks like a PITA to me. like we would need > a spoon, and all we have is a hammer, so we start eating our > soup with the hammer... > > i have the definite feeling that gconcat serves a whole different > propose. Maybe gvirstor is what you want? http://wiki.freebsd.org/gvirstor Eric From owner-freebsd-geom@FreeBSD.ORG Mon Apr 9 15:19:06 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 11A2D16A400; Mon, 9 Apr 2007 15:19:06 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) by mx1.freebsd.org (Postfix) with ESMTP id 5F40913C484; Mon, 9 Apr 2007 15:19:05 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from localhost (marvin-mail [192.168.0.2]) by marvin.harmless.hu (Postfix) with ESMTP id 766287BFCD7; Mon, 9 Apr 2007 17:19:03 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.4.2 (20060627) (Debian) at harmless.hu Received: from marvin.harmless.hu ([192.168.0.2]) by localhost (marvin.harmless.hu [192.168.0.2]) (amavisd-new, port 10024) with ESMTP id LderHByHYl3H; Mon, 9 Apr 2007 17:19:03 +0200 (CEST) Received: from marvin.harmless.hu (localhost [127.0.0.1]) by marvin.harmless.hu (Postfix) with ESMTP id 080297BFCD1; Mon, 9 Apr 2007 17:19:02 +0200 (CEST) Date: Mon, 9 Apr 2007 17:19:02 +0200 From: Gergely CZUCZY To: Eric Anderson Message-ID: <20070409151902.GA87807@harmless.hu> References: <20070408140215.GA54201@harmless.hu> <86k5wmu420.fsf@dwp.des.no> <20070408181916.GA59715@harmless.hu> <86bqhyu225.fsf@dwp.des.no> <461A4D93.3010200@freebsd.org> <20070409143818.GA86722@harmless.hu> <461A5812.1080205@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline In-Reply-To: <461A5812.1080205@freebsd.org> User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: freebsd-geom@freebsd.org Subject: Re: volume management 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, 09 Apr 2007 15:19:06 -0000 --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 09, 2007 at 10:13:22AM -0500, Eric Anderson wrote: > On 04/09/07 09:38, Gergely CZUCZY wrote: > >On Mon, Apr 09, 2007 at 09:28:35AM -0500, Eric Anderson wrote: > >>On 04/08/07 13:57, Dag-Erling Sm=C3=83=C2=B8rgrav wrote: > >>>Gergely CZUCZY writes: > >>>>yeap, i know about ZFS, as i assume, it will need around 1.5-2 years > >>>>from now, when 7.0-RELEASE will be ready. > >>>No, it's expected this fall. > >>>>and i'm looking for a solution for a production environment within > >>>>a year. > >>>There is no other solution. > >>How about gconcat? You could create a mirror, then gconcat another mir= ror, etc, extending the=20 > >>GEOM. Then run growfs on that extended volume. Wouldn't that work? > >why gmirror? gconcat somehow could be used for this, > >but > >1) i see no attach operation for gconcat to add > >providers on the fly. > >2) this would require to always create subpartitions/bsdlabels > >on the disk, and add a bit more on need. > >like the following example: > > - there are 4 filesystems by default: fs1,fs2,fs3,fs4 > > - given da0s1g the "reminder" of the disks, that will give > > the space needed for the services. we allocate 4 labels for > > the services: da0s1ga, da0s2gd, da0s2ge, da0s2gf > > - we concat the four bsdlabels, to be able to later on enlarge them. > >now increasing the size would look like ( _IF_ gconcat would support it): > > - creating a new bsdlabel, that would serve as the incrementum, like > > we add da0s2gg > > NOTE: we reach "h" we cannot add more, bsdlables are limited. we would > > have to recursively bsdlabel all the last bsdlabels to have te ability > > to chop another piece that could be added later on. > > - attaching the new partition to the already existing concat > > - growing the filesystem > >all of this looks like a PITA to me. like we would need > >a spoon, and all we have is a hammer, so we start eating our > >soup with the hammer... > >i have the definite feeling that gconcat serves a whole different > >propose. >=20 >=20 > Maybe gvirstor is what you want? >=20 > http://wiki.freebsd.org/gvirstor similar, yes. but this wiki page is quite foggy on exactly how does gvirstor works, what can it do, how does it do that, and so on. even the provided example is a bit undecryptable, and without any comments (that screenshot). i've checked this previously, and wasn't able to decide whether i need this or not. and also, there wasn't any remarks on the tarballs to what to do with them, and for which branch were they made for. but might worth a try, yes. Bye, Gergely Czuczy mailto: gergely.czuczy@harmless.hu --=20 Weenies test. Geniuses solve problems that arise. --0OAP2g/MAC+5xKAE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) owGFVk2P5EYZ3iRCSI445BQFCenVXjYL7p7+2GFmG2aGyWQ2RGKziB0U7eYQVdtl uzR2lVNVbo/3QHKJlMMiIQQiEhK57gWJA/wA/gBH/gRI/AEOPG+V3RshIQ7d7XbV +1HP87zvW7/61mu3Xn3jb3/680ffe/7r37/yx9dpmzad97qcNcLulJ4tF4vl7Pjo eHGEx9myWH6/KO5t13J9eLiWhw++/aS4MNpL7WdXQys35OWNP2hrofQPKKuEddKf dL6YHSfTvneVa41TXhm9IaVrpeV+7coK7QppZ5c6M7nS5YY+6YyX+ay1SnuxrWWS PNL00OiUzltLi/sprRaLIxKelovNcr1Zrc4f0mxxuFikdGlVRuc6l9YZTb2Fp01y SnCwuHewuH8Au8X9zfo4pfekLWU90MXTn188ffJy6+n/Cga71fFmffh/g52ejuGO ORwSPDxK6V1Rzi4tjl7S4+bkYn1yvD65WJ28c2xLK3ZfNz79r8x+2FZGNurmR8C2 qaVz86o7hYHy0o0Wp4MUbUqKrrXpSWxN5+npg8cpCYeXwrmukVj21Ku6Ji1lTsKa Tue0nB/OVgRz60ZXhTUNwU1KfSU1Hc0Xs59d/uTy/PFltN5KslLkwzzu/8Cw4zuO 5E0rM/BGvlKOClHX445TgTjqTkO1Mdd8/sJYEuRM3bEixr+tNXmXhRdS75Q1uoE8 EBLu9OQoJDq6vaqklYRQ2pDx+LP3GDf8eI9EmRmdCX9G9MR0lJmuzinDGbxE3EZZ a2yKrHHYcScJHT1i8SQJy9Jn+LqBZFmjvPtktQhx3rt89HBOdMX2toMPa/rCEc7h K7iKNoBlh+waiZ0fcgL6jo/rvbHXZ+yorwYqYzZn+0ScaWSFg8SkAX3n4IoRY5RT ttt2nn+Wd8G0k5LhEN6LrCLTSiv2EE8uPdbznE0A+U6xeGOykoo6srq6G0nsQ1Qr P+kUoGbDuheDm8Bz3bYV1oe6dgdbl9diK+ugo9Fhrtw1RAj+ERJgbyHBxsAX1lmF IVqtrmUMb+ra9AyvvBFNW8d6oBkvwkbgc48KhRIYnJeNo+1AuSxEV/sNFW6ZFm6F zxqfe6NlqXagJRcLtwyk0W2LUuKKvU2m2Ofo0pEMFjjbBHNeda3IZMh1jzteSjTK TLo59UgLSWcMB5KLAPC+lw7GvZsxC5GGh1WZTw9yeijGpOF04iqg0lnag5syDdAB 90V+rBHZUiiaWqBtsEkTYOVOoDRT5UbFklPP5Egq1yIF5N+mj99/8PFeHnHZdW1r rEdl351ICKSzJwE4+n1GE3LRDIeV3HQ4WgjORdw1aQgVHDFi0EI8cRleffDo6nLD C4gA2d6ubgcIhEYVhs0smXSMCPaDEmrVoAHmgYIQPLiqxC7AYmXWWQci0UanTJmp kFgtnH+JKG+PZoyqqpUfInkG08y0+17QKpnJeNh9NSI5yGLiYD4iFctvAp3B2pcJ e+WXog49FEJXLoAa0Z9Ua2MZBPr3eudFPkLQLaqTKXSRQ0E/ff/qnJ1zhwmvJliC doMptGx4roVyhB/sCOeGK4GnppHoc87we+eRMI18Q39s70zXhnYc0or75/NwZjUC yNUkC6VBDBVS1vEMwr9sZ6wPDtdXpubSKzD5oZCxG+GSIOEwdNbYXh+KATCXmAfO o/i4J7G/AX28F9qfTfsq79vNwUGvrtW8sFKC3bmx5cFkmTjIBQWSYoKgbNEzxw4H A7BTBhTQ5jhxU5ZDqKgbkXnoB/03yQ3S3qfBPdulMRXIlAdrjjHIjTpsDP/DyQPa CUCFOkhyL2KQxsabT30uUsDNESNZZnZow70nUsWQY4olQg9QScMF5ejtAKtDgUnt KuPvzjFhQUFWyex6msGtlTtlOlcPMY1eOB47U+tAJCTBUz7oW8V7QbDEGaH6eRKl 4kw6tuDJA1JBaQugMI0OCGYLUYVqYlwSDmD2emniWbiB9pVCkW9x7cNPz16xPlAj csYe0z1hdhpVVmE4wl6Qt0NkLkmSdwaZJsn+jvSsy54NSSNU7c2Gyvh6noXXX78x Jclsxlr5EIgpcITLk5/jEqgVRqrju8MuEANwGhdVK6xiPX5x9to3bvG1d7o0v/Hq p1/e+qpxv9t997cv5FvNK6//5sWLg1/+89+f3/rqwfO31F+/85dPf/GP53/41zc/ +/vTL5+8+R8= =U18H -----END PGP SIGNATURE----- --0OAP2g/MAC+5xKAE-- From owner-freebsd-geom@FreeBSD.ORG Mon Apr 9 15:24:26 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2080C16A401; Mon, 9 Apr 2007 15:24:26 +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 A3AC013C483; Mon, 9 Apr 2007 15:24:25 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 272C945B26; Mon, 9 Apr 2007 17:24:24 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id EEA6C45696; Mon, 9 Apr 2007 17:24:11 +0200 (CEST) Date: Mon, 9 Apr 2007 17:24:01 +0200 From: Pawel Jakub Dawidek To: Gergely CZUCZY Message-ID: <20070409152401.GG76673@garage.freebsd.pl> References: <20070408140215.GA54201@harmless.hu> <86k5wmu420.fsf@dwp.des.no> <20070408181916.GA59715@harmless.hu> <86bqhyu225.fsf@dwp.des.no> <461A4D93.3010200@freebsd.org> <20070409143818.GA86722@harmless.hu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+1TulI7fc0PCHNy3" Content-Disposition: inline In-Reply-To: <20070409143818.GA86722@harmless.hu> 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=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-geom@freebsd.org Subject: Re: volume management 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, 09 Apr 2007 15:24:26 -0000 --+1TulI7fc0PCHNy3 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 09, 2007 at 04:38:18PM +0200, Gergely CZUCZY wrote: > On Mon, Apr 09, 2007 at 09:28:35AM -0500, Eric Anderson wrote: > > On 04/08/07 13:57, Dag-Erling Sm??rgrav wrote: > > >Gergely CZUCZY writes: > > >>yeap, i know about ZFS, as i assume, it will need around 1.5-2 years > > >>from now, when 7.0-RELEASE will be ready. > > >No, it's expected this fall. > > >>and i'm looking for a solution for a production environment within > > >>a year. > > >There is no other solution. > >=20 > > How about gconcat? You could create a mirror, then gconcat another mir= ror, etc, extending the GEOM.=20 > > Then run growfs on that extended volume. Wouldn't that work? > why gmirror? gconcat somehow could be used for this, > but > 1) i see no attach operation for gconcat to add > providers on the fly. > 2) this would require to always create subpartitions/bsdlabels > on the disk, and add a bit more on need. Slow down:) Implementing off-line 'attach' operation is trivial and on-line 'attach' operation is also easy, but because you need to unmount file system anyway, off-line attach is ok. Let's assume you have currently two disks: da0 and da1. # gconcat label foo da0 da1 # newfs /dev/concat/foo # mount /dev/concat/foo /foo and you want to extend your storage by adding two disks: da2 and da3: # umount /foo # gconcat stop foo # gconcat label foo da0 da1 da2 da3 # growfs /dev/concat/foo # mount /dev/concat/foo /foo That's all. You can operate on mirrors too: # gmirror label foo0 da0 da1 # gconcat label foo mirror/foo0 # newfs /dev/concat/foo # mount /dev/concat/foo /foo And extending: # gmirror label foo1 da2 da3 # umount /foo # gconcat stop foo # gconcat label foo mirror/foo0 mirror/foo1 # growfs /dev/concat/foo # mount /dev/concat/foo /foo --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --+1TulI7fc0PCHNy3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGGlqRForvXbEpPzQRAgn3AKCYGjzzSwHQ3YQoM4MfcFidOPuGRACeL59S LgWMgtl4DMxHTPGNMyQEpdg= =+6u+ -----END PGP SIGNATURE----- --+1TulI7fc0PCHNy3-- From owner-freebsd-geom@FreeBSD.ORG Mon Apr 9 15:29:30 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4CE1C16A403; Mon, 9 Apr 2007 15:29:30 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id 1FA3A13C4AE; Mon, 9 Apr 2007 15:29:29 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l39FTTsu050763; Mon, 9 Apr 2007 10:29:29 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <461A5BD9.1050504@freebsd.org> Date: Mon, 09 Apr 2007 10:29:29 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.10 (X11/20070320) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20070408140215.GA54201@harmless.hu> <86k5wmu420.fsf@dwp.des.no> <20070408181916.GA59715@harmless.hu> <86bqhyu225.fsf@dwp.des.no> <461A4D93.3010200@freebsd.org> <20070409143818.GA86722@harmless.hu> <20070409152401.GG76673@garage.freebsd.pl> In-Reply-To: <20070409152401.GG76673@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/3052/Mon Apr 9 07:23:53 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: Gergely CZUCZY , freebsd-geom@freebsd.org Subject: Re: volume management 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, 09 Apr 2007 15:29:30 -0000 On 04/09/07 10:24, Pawel Jakub Dawidek wrote: > On Mon, Apr 09, 2007 at 04:38:18PM +0200, Gergely CZUCZY wrote: >> On Mon, Apr 09, 2007 at 09:28:35AM -0500, Eric Anderson wrote: >>> On 04/08/07 13:57, Dag-Erling Sm??rgrav wrote: >>>> Gergely CZUCZY writes: >>>>> yeap, i know about ZFS, as i assume, it will need around 1.5-2 years >>>> >from now, when 7.0-RELEASE will be ready. >>>> No, it's expected this fall. >>>>> and i'm looking for a solution for a production environment within >>>>> a year. >>>> There is no other solution. >>> How about gconcat? You could create a mirror, then gconcat another mirror, etc, extending the GEOM. >>> Then run growfs on that extended volume. Wouldn't that work? >> why gmirror? gconcat somehow could be used for this, >> but >> 1) i see no attach operation for gconcat to add >> providers on the fly. >> 2) this would require to always create subpartitions/bsdlabels >> on the disk, and add a bit more on need. > > Slow down:) Implementing off-line 'attach' operation is trivial and > on-line 'attach' operation is also easy, but because you need to unmount > file system anyway, off-line attach is ok. > > Let's assume you have currently two disks: da0 and da1. > > # gconcat label foo da0 da1 > # newfs /dev/concat/foo > # mount /dev/concat/foo /foo > > and you want to extend your storage by adding two disks: da2 and da3: > > # umount /foo > # gconcat stop foo > # gconcat label foo da0 da1 da2 da3 > # growfs /dev/concat/foo > # mount /dev/concat/foo /foo > > That's all. > > You can operate on mirrors too: > > # gmirror label foo0 da0 da1 > # gconcat label foo mirror/foo0 > # newfs /dev/concat/foo > # mount /dev/concat/foo /foo > > And extending: > > # gmirror label foo1 da2 da3 > # umount /foo > # gconcat stop foo > # gconcat label foo mirror/foo0 mirror/foo1 > # growfs /dev/concat/foo > # mount /dev/concat/foo /foo > Pawel, that is precisely what I had in mind. One question - lets say support for online growfs was available - how would gconcat need to be modified to support that? Eric From owner-freebsd-geom@FreeBSD.ORG Mon Apr 9 15:31:46 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EB6C716A401; Mon, 9 Apr 2007 15:31:46 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id AC1B213C4BD; Mon, 9 Apr 2007 15:31:46 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 2410020A1; Mon, 9 Apr 2007 17:31:40 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 144D82091; Mon, 9 Apr 2007 17:31:40 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id 029CDA10AC; Mon, 9 Apr 2007 17:31:40 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Eric Anderson References: <20070408140215.GA54201@harmless.hu> <86k5wmu420.fsf@dwp.des.no> <20070408181916.GA59715@harmless.hu> <86bqhyu225.fsf@dwp.des.no> <461A4D93.3010200@freebsd.org> Date: Mon, 09 Apr 2007 17:31:39 +0200 In-Reply-To: <461A4D93.3010200@freebsd.org> (Eric Anderson's message of "Mon, 09 Apr 2007 09:28:35 -0500") Message-ID: <86wt0lef8k.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Gergely CZUCZY , freebsd-geom@freebsd.org Subject: Re: volume management 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, 09 Apr 2007 15:31:47 -0000 Eric Anderson writes: > How about gconcat? You could create a mirror, then gconcat another > mirror, etc, extending the GEOM. Then run growfs on that extended > volume. Wouldn't that work? Yes, but it would be very unwieldy. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-geom@FreeBSD.ORG Mon Apr 9 15:32:05 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E61A016A402 for ; Mon, 9 Apr 2007 15:32:05 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) by mx1.freebsd.org (Postfix) with ESMTP id 529BC13C43E for ; Mon, 9 Apr 2007 15:32:05 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from localhost (marvin-mail [192.168.0.2]) by marvin.harmless.hu (Postfix) with ESMTP id 3AC8F7BFCD1; Mon, 9 Apr 2007 17:32:04 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.4.2 (20060627) (Debian) at harmless.hu Received: from marvin.harmless.hu ([192.168.0.2]) by localhost (marvin.harmless.hu [192.168.0.2]) (amavisd-new, port 10024) with ESMTP id uDuqg8UduyzI; Mon, 9 Apr 2007 17:32:03 +0200 (CEST) Received: from marvin.harmless.hu (localhost [127.0.0.1]) by marvin.harmless.hu (Postfix) with ESMTP id BC7B97C0BE0; Mon, 9 Apr 2007 17:32:03 +0200 (CEST) Date: Mon, 9 Apr 2007 17:32:03 +0200 From: Gergely CZUCZY To: Pawel Jakub Dawidek Message-ID: <20070409153203.GA88082@harmless.hu> References: <20070408140215.GA54201@harmless.hu> <86k5wmu420.fsf@dwp.des.no> <20070408181916.GA59715@harmless.hu> <86bqhyu225.fsf@dwp.des.no> <461A4D93.3010200@freebsd.org> <20070409143818.GA86722@harmless.hu> <20070409152401.GG76673@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline In-Reply-To: <20070409152401.GG76673@garage.freebsd.pl> User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: freebsd-geom@freebsd.org Subject: Re: volume management 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, 09 Apr 2007 15:32:06 -0000 --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 09, 2007 at 05:24:01PM +0200, Pawel Jakub Dawidek wrote: > On Mon, Apr 09, 2007 at 04:38:18PM +0200, Gergely CZUCZY wrote: > > On Mon, Apr 09, 2007 at 09:28:35AM -0500, Eric Anderson wrote: > > > On 04/08/07 13:57, Dag-Erling Sm??rgrav wrote: > > > >Gergely CZUCZY writes: > > > >>yeap, i know about ZFS, as i assume, it will need around 1.5-2 years > > > >>from now, when 7.0-RELEASE will be ready. > > > >No, it's expected this fall. > > > >>and i'm looking for a solution for a production environment within > > > >>a year. > > > >There is no other solution. > > >=20 > > > How about gconcat? You could create a mirror, then gconcat another m= irror, etc, extending the GEOM.=20 > > > Then run growfs on that extended volume. Wouldn't that work? > > why gmirror? gconcat somehow could be used for this, > > but > > 1) i see no attach operation for gconcat to add > > providers on the fly. > > 2) this would require to always create subpartitions/bsdlabels > > on the disk, and add a bit more on need. >=20 > Slow down:) Implementing off-line 'attach' operation is trivial and > on-line 'attach' operation is also easy, but because you need to unmount > file system anyway, off-line attach is ok. >=20 > Let's assume you have currently two disks: da0 and da1. >=20 > # gconcat label foo da0 da1 > # newfs /dev/concat/foo > # mount /dev/concat/foo /foo >=20 > and you want to extend your storage by adding two disks: da2 and da3: >=20 > # umount /foo > # gconcat stop foo > # gconcat label foo da0 da1 da2 da3 > # growfs /dev/concat/foo > # mount /dev/concat/foo /foo >=20 > That's all. >=20 > You can operate on mirrors too: >=20 > # gmirror label foo0 da0 da1 > # gconcat label foo mirror/foo0 > # newfs /dev/concat/foo > # mount /dev/concat/foo /foo >=20 > And extending: >=20 > # gmirror label foo1 da2 da3 > # umount /foo > # gconcat stop foo > # gconcat label foo mirror/foo0 mirror/foo1 > # growfs /dev/concat/foo > # mount /dev/concat/foo /foo yes, this was the trivial part, but: 1) to increment them, i need a device(disk/slice/label/etc). if i increment a lot, i need a lot of devices. 2) these incrementum-devices (the ones i increment by), have to be made, each of the has to be chopped from the storage pool. please also look at the bsdlabel issue i have mentioned. gconcating is the most easy part of that. recursively bsdlabeling is what i have mostly referred to as the real issue. i really don't think this is the way to do it... if you are down to the bits: we are running our systems on 3ware cards. the end of the disk (usually total-20G) is the storage pool. under linux's LVM2 we use this as a pool to allocate space for our services. At the startup only a minimal part of the pool is used, and as a service needs more space, we enlarge its available space, by little increments. so, we are not adding new disks, or anything, as you have assumed in your upper examples. we just give it a bit more space, nothing special. new disks are not being added, that's why i had said "storage pool", to reflect this situation. it wasn't just a term for an abstraction level :) >=20 > --=20 > Pawel Jakub Dawidek http://www.wheel.pl > pjd@FreeBSD.org http://www.FreeBSD.org > FreeBSD committer Am I Evil? Yes, I Am! Bye, Gergely Czuczy mailto: gergely.czuczy@harmless.hu --=20 Weenies test. Geniuses solve problems that arise. --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) owGtV79vHMcVpmWkyAIO4JRJ8+IUFKG7vR8UTfpskaYlSlEgxkZIx5AcwJjbnbsb c3dmPTN7y1PSuAiQIkWSNoX/ggAunCZA/gV3QQykSZG/wED6fG9mb3mSLBVOWJDc nXnfvB/ffO/t7195eevaq19+/sWHN373xz+99Ofv7U9vlLX3et4vhV0q3R8Nh6P+ wcHwYNx/vb8r9saZnM1eH2dTme/v3f3BL91to73Uvn++quSEvLz0g6oQSr9J2UJY J/2t2s/6B8l63x3lKuOUV0ZPSOlCadmtnVuh3Uza/onOTK70fEKf1MbLvF9Zpb2Y FjJJ3tV0anSPjitLwzd6NB4O90l4Gu5Nxjcnw9F7p3RjiJc9ek80sqCfiot6SndE o3J5QY0F3iQ5pOfC3JzsHkxGB1cw96Sdy2JFtx+9f/vRwyuEF2C8MRkfTHb3jk+p P9xjjBOrMjrWubTO6E2IADK8ORgeDGA72p3s7ffg7Lx/YpGaOZ2VR0d2bsXySaPD p5x6q1oYWarLt5HzspDOpYv6ECbKS9fZHK6kqHqk6EKbhsTU1J4e3T3rkXB4KZyr S4llT40qCtJS5iSsqXVOo3SvPyaYW9eBzawpCUA9ahZS03467P/85MHJ8dlJtJ9K slLkq3Rt8TPD4NuO5GUlM1SV/EI5momi6PYcCpymtksqjLng+GfGkiBnipoZ0z5W 1uR1Fl5IvVTW6BL0wbEA1FdQweEO+nwhrSQcqA0Zj4cOtd1yazxs9/6kS888MzoT /ojooakpM3WRU4awvIQbpbLW2B7CQPztThI6gpe3knZZ+gy/LsFwpjTvpnsn756m V+fROSPYGijWNDNHCMwvABatkKklXC1lSvQBu6C3fVxvjL04CiDNYkXz6NBR54sz pVwglug3ClI7YHEOOfO9YDitffg72gEHnJScHuG9yBZkKmlFl/Y1qMd6ngcb1GGp mNPRYUmzoi33eCcWtwknW/lJrZB8Ni0asXLrHLp6Wgnrgxq4wdTlhZjKInKshcyV uwBDQQuciqRPwc/SAAzrTFGcFxN5ViDS3DR6skP3y6qQzAlOuJnN+iwztB3j2t4I DC56q5ZKFHxEwqe+aK8onCEp3KrHeUNGM4GU0grcCNcFAda6xJXhnM5UgQhXzssS 4CvE3bvypU0xMM1FF8IDydcjXsQAuhBLSVltLULBZfeNCflwE8rFMCQlF6PO/Ls/ 7ooU8oiymbARm+KylsyuQS6Xg7hxgC1xKXj99BLF9QjPx7FTjdCBBZGc/ApXyRsr 5pKmKy5ToPmmr+PW193Jhq91e2TnQkdbbyp65u0zIQVcYLbb4s35lrGd4zZx6oMU xVfhwgvdEiDwLd4vUMaYzUDae3fl4fDJrD8bQTRgB4b/h8Kgr1zpywsdeypn37oC G/5v/D/6nyqxkq7Xigb6EV/99c1kiQgXbpIkkClQT2kISNB87Cu5pcVuRQBWmbzO xBu4Av8OgtMDaPBOmqgZdl7ZCnQZv2GMJ1zQFsOlSRAxifvdmdRlv12l6+yh0dI9 ATld7fSScGvhJQS3FDlaqgxqOgtBLTi4sJYtTFWxHnMjxVKyvkSVMaBhAgkTODxo DrdDniwYYS2TEA9Xw7moEkHt4A8Esa0X30IVM1ka54NuhVxGV4RPIcwQF6eWmCSS NWxr1nB/WWPDHPJjJWYzG2UuliiBjLd+pNjMT9iXm9iglL6IBW29gALCNMlRP5+m iBD1YEERUHMWbsYNASoP1WhkWEBX1EHFWWWCmLoEV3G34cVM2NylwYilqE0xV5+u 164O3njjRdEfD++hwbmE15/IMwQbHYwQdn0JBXjwi9MxH82yHnxHoCLsTEL3KkwW GlclMhnaYvBL2kgZOo4lch5privwA4nlQUGrsiXy2kmG5MRwS277G5/UQgVKuiQ0 unBWj52SuhAY+5A+bF0KVfBEvF6H9BbK+2KDruCwM711JjGYrMUZchPFGR3JcnPi Ys3DINi1ndiG8kTpKPE1yGqhM4J7K0IF6sc1aDUHfXho3GjNrUc8CQE2cRj3cI9R 8O7czqGpZH/gFmfBRxXmWYaZl5MTKqfXNuv1Wo/rACYWGCFjhfAxUYcOnYbZVThm X3BN4HvElnFo1JjonLcijI1JIcF5muwka7Xs9+Pfb/pm+OafhffVZDBomibFACyL tCpgX32cv33XSvnO2Z3U2PlzbJ+y3zAARPuEqa0sUVAk/Xk/xyXdp5OlKo7oIavn fbz5UYKfd1aylyTdN8LjOnu8SkoQxpsJzePrNAuvN78YkiSm4QMptYKy4eMBInEP D2Cp43kZpcbQB9aVLk6gwion0+S3Ry9/Z4s/B9ffkq9e+9cPtz4r//Pp339z7S// fPNvL300u/al+scffvXV1mePP3/w9b/to62/fvrrL75+v/z+V3dXH/0X =hDYX -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG-- From owner-freebsd-geom@FreeBSD.ORG Mon Apr 9 15:36:11 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AD2DD16A403; Mon, 9 Apr 2007 15:36:11 +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 0E7D913C4C8; Mon, 9 Apr 2007 15:36:11 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id EF3B445B26; Mon, 9 Apr 2007 17:36:08 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 1D51D45683; Mon, 9 Apr 2007 17:35:56 +0200 (CEST) Date: Mon, 9 Apr 2007 17:35:44 +0200 From: Pawel Jakub Dawidek To: Eric Anderson Message-ID: <20070409153544.GI76673@garage.freebsd.pl> References: <20070408140215.GA54201@harmless.hu> <86k5wmu420.fsf@dwp.des.no> <20070408181916.GA59715@harmless.hu> <86bqhyu225.fsf@dwp.des.no> <461A4D93.3010200@freebsd.org> <20070409143818.GA86722@harmless.hu> <20070409152401.GG76673@garage.freebsd.pl> <461A5BD9.1050504@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qLni7iB6Dl8qUSwk" Content-Disposition: inline In-Reply-To: <461A5BD9.1050504@freebsd.org> 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=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: Gergely CZUCZY , freebsd-geom@freebsd.org Subject: Re: volume management 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, 09 Apr 2007 15:36:11 -0000 --qLni7iB6Dl8qUSwk Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 09, 2007 at 10:29:29AM -0500, Eric Anderson wrote: > One question - lets say support for online growfs was available - how wou= ld gconcat need to be modified to support that? You would need to add 'attach' command which will go to the kernel, add new provider and change concat/foo provider's mediasize. It will work similar to how 'gmirror insert' work except that for gmirror you don't change mediasize. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --qLni7iB6Dl8qUSwk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGGl1QForvXbEpPzQRAufYAJ4mHhCFuC7RRNS2P0k/v1zVaxEABwCfY/A7 fiUNlBXwVRGcacyyoQtq8Xw= =Eudj -----END PGP SIGNATURE----- --qLni7iB6Dl8qUSwk-- From owner-freebsd-geom@FreeBSD.ORG Mon Apr 9 15:42:00 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 169CB16A402; Mon, 9 Apr 2007 15:42:00 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id E9B8D13C4BE; Mon, 9 Apr 2007 15:41:59 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l39FfwMH053075; Mon, 9 Apr 2007 10:41:59 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <461A5EC6.8010000@freebsd.org> Date: Mon, 09 Apr 2007 10:41:58 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.10 (X11/20070320) MIME-Version: 1.0 To: Gergely CZUCZY References: <20070408140215.GA54201@harmless.hu> <86k5wmu420.fsf@dwp.des.no> <20070408181916.GA59715@harmless.hu> <86bqhyu225.fsf@dwp.des.no> <461A4D93.3010200@freebsd.org> <20070409143818.GA86722@harmless.hu> <20070409152401.GG76673@garage.freebsd.pl> <20070409153203.GA88082@harmless.hu> In-Reply-To: <20070409153203.GA88082@harmless.hu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/3054/Mon Apr 9 09:31:59 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: Pawel Jakub Dawidek , freebsd-geom@freebsd.org Subject: Re: volume management 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, 09 Apr 2007 15:42:00 -0000 On 04/09/07 10:32, Gergely CZUCZY wrote: > On Mon, Apr 09, 2007 at 05:24:01PM +0200, Pawel Jakub Dawidek wrote: >> On Mon, Apr 09, 2007 at 04:38:18PM +0200, Gergely CZUCZY wrote: >>> On Mon, Apr 09, 2007 at 09:28:35AM -0500, Eric Anderson wrote: >>>> On 04/08/07 13:57, Dag-Erling Sm??rgrav wrote: >>>>> Gergely CZUCZY writes: >>>>>> yeap, i know about ZFS, as i assume, it will need around 1.5-2 years >>>>> >from now, when 7.0-RELEASE will be ready. >>>>> No, it's expected this fall. >>>>>> and i'm looking for a solution for a production environment within >>>>>> a year. >>>>> There is no other solution. >>>> How about gconcat? You could create a mirror, then gconcat another mirror, etc, extending the GEOM. >>>> Then run growfs on that extended volume. Wouldn't that work? >>> why gmirror? gconcat somehow could be used for this, >>> but >>> 1) i see no attach operation for gconcat to add >>> providers on the fly. >>> 2) this would require to always create subpartitions/bsdlabels >>> on the disk, and add a bit more on need. >> Slow down:) Implementing off-line 'attach' operation is trivial and >> on-line 'attach' operation is also easy, but because you need to unmount >> file system anyway, off-line attach is ok. >> >> Let's assume you have currently two disks: da0 and da1. >> >> # gconcat label foo da0 da1 >> # newfs /dev/concat/foo >> # mount /dev/concat/foo /foo >> >> and you want to extend your storage by adding two disks: da2 and da3: >> >> # umount /foo >> # gconcat stop foo >> # gconcat label foo da0 da1 da2 da3 >> # growfs /dev/concat/foo >> # mount /dev/concat/foo /foo >> >> That's all. >> >> You can operate on mirrors too: >> >> # gmirror label foo0 da0 da1 >> # gconcat label foo mirror/foo0 >> # newfs /dev/concat/foo >> # mount /dev/concat/foo /foo >> >> And extending: >> >> # gmirror label foo1 da2 da3 >> # umount /foo >> # gconcat stop foo >> # gconcat label foo mirror/foo0 mirror/foo1 >> # growfs /dev/concat/foo >> # mount /dev/concat/foo /foo > yes, this was the trivial part, but: > > 1) to increment them, i need a device(disk/slice/label/etc). > if i increment a lot, i need a lot of devices. > 2) these incrementum-devices (the ones i increment by), > have to be made, each of the has to be chopped from the > storage pool. > > please also look at the bsdlabel issue i have mentioned. > gconcating is the most easy part of that. recursively > bsdlabeling is what i have mostly referred to as the > real issue. i really don't think this is the way to > do it... > > if you are down to the bits: we are running our systems > on 3ware cards. the end of the disk (usually total-20G) is > the storage pool. under linux's LVM2 we use this as a pool > to allocate space for our services. At the startup only > a minimal part of the pool is used, and as a service needs > more space, we enlarge its available space, by little increments. > so, we are not adding new disks, or anything, as you have assumed > in your upper examples. we just give it a bit more space, nothing > special. > > new disks are not being added, that's why i had said "storage pool", > to reflect this situation. it wasn't just a term for an abstraction > level :) I really think gvirstor is a good fit for you. Search this list for some info on it, or just play with it a bit. The author is active on this list and so he'll probably pipe up. Eric From owner-freebsd-geom@FreeBSD.ORG Mon Apr 9 15:42:25 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D917616A40A; Mon, 9 Apr 2007 15:42:25 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 9BAD413C45A; Mon, 9 Apr 2007 15:42:25 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id EC7C620A1; Mon, 9 Apr 2007 17:42:18 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id DBD772094; Mon, 9 Apr 2007 17:42:18 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id C7CDEA10AC; Mon, 9 Apr 2007 17:42:18 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Eric Anderson References: <20070408140215.GA54201@harmless.hu> <86k5wmu420.fsf@dwp.des.no> <461A4DDC.2090307@freebsd.org> Date: Mon, 09 Apr 2007 17:42:18 +0200 In-Reply-To: <461A4DDC.2090307@freebsd.org> (Eric Anderson's message of "Mon, 09 Apr 2007 09:29:48 -0500") Message-ID: <86odlxeeqt.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Gergely CZUCZY , freebsd-geom@freebsd.org Subject: Re: volume management 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, 09 Apr 2007 15:42:25 -0000 Eric Anderson writes: > On 04/08/07 13:14, Dag-Erling Sm=F8rgrav wrote: > > ZFS in -CURRENT does that and more. I also have unfinished code for a > > GEOM-based LVM, but none of FreeBSD's file systems support on-the-fly > > resizing, so ZFS is really your best option. > Is that code available in P4 somewhere (or elsewhere)? Sounds > interesting. There's a patch in . It's quite old, though. The file system that held my glvm tree crashed, so it only exists as a compressed dump right now. I'll try to get it back from the dead tomorrow, and possibly stick it in p4. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-geom@FreeBSD.ORG Mon Apr 9 15:44:11 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0F0DC16A46F; Mon, 9 Apr 2007 15:44:11 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) by mx1.freebsd.org (Postfix) with ESMTP id 63F8C13C4B7; Mon, 9 Apr 2007 15:44:09 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from localhost (marvin-mail [192.168.0.2]) by marvin.harmless.hu (Postfix) with ESMTP id 4F0537BFCD0; Mon, 9 Apr 2007 17:44:08 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.4.2 (20060627) (Debian) at harmless.hu Received: from marvin.harmless.hu ([192.168.0.2]) by localhost (marvin.harmless.hu [192.168.0.2]) (amavisd-new, port 10024) with ESMTP id lL74jkTajHbm; Mon, 9 Apr 2007 17:44:08 +0200 (CEST) Received: from marvin.harmless.hu (localhost [127.0.0.1]) by marvin.harmless.hu (Postfix) with ESMTP id D11607BFCC6; Mon, 9 Apr 2007 17:44:07 +0200 (CEST) Date: Mon, 9 Apr 2007 17:44:07 +0200 From: Gergely CZUCZY To: Eric Anderson Message-ID: <20070409154407.GA88621@harmless.hu> References: <20070408140215.GA54201@harmless.hu> <86k5wmu420.fsf@dwp.des.no> <20070408181916.GA59715@harmless.hu> <86bqhyu225.fsf@dwp.des.no> <461A4D93.3010200@freebsd.org> <20070409143818.GA86722@harmless.hu> <20070409152401.GG76673@garage.freebsd.pl> <20070409153203.GA88082@harmless.hu> <461A5EC6.8010000@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline In-Reply-To: <461A5EC6.8010000@freebsd.org> User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: freebsd-geom@freebsd.org Subject: Re: volume management 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, 09 Apr 2007 15:44:11 -0000 --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 09, 2007 at 10:41:58AM -0500, Eric Anderson wrote: > On 04/09/07 10:32, Gergely CZUCZY wrote: > >On Mon, Apr 09, 2007 at 05:24:01PM +0200, Pawel Jakub Dawidek wrote: > >>On Mon, Apr 09, 2007 at 04:38:18PM +0200, Gergely CZUCZY wrote: > >>>On Mon, Apr 09, 2007 at 09:28:35AM -0500, Eric Anderson wrote: > >>>>On 04/08/07 13:57, Dag-Erling Sm??rgrav wrote: > >>>>>Gergely CZUCZY writes: > >>>>>>yeap, i know about ZFS, as i assume, it will need around 1.5-2 years > >>>>>>from now, when 7.0-RELEASE will be ready. > >>>>>No, it's expected this fall. > >>>>>>and i'm looking for a solution for a production environment within > >>>>>>a year. > >>>>>There is no other solution. > >>>>How about gconcat? You could create a mirror, then gconcat another m= irror, etc, extending the=20 > >>>>GEOM. Then run growfs on that extended volume. Wouldn't that work? > >>>why gmirror? gconcat somehow could be used for this, > >>>but > >>>1) i see no attach operation for gconcat to add > >>>providers on the fly. > >>>2) this would require to always create subpartitions/bsdlabels > >>>on the disk, and add a bit more on need. > >>Slow down:) Implementing off-line 'attach' operation is trivial and > >>on-line 'attach' operation is also easy, but because you need to unmount > >>file system anyway, off-line attach is ok. > >> > >>Let's assume you have currently two disks: da0 and da1. > >> > >> # gconcat label foo da0 da1 > >> # newfs /dev/concat/foo > >> # mount /dev/concat/foo /foo > >> > >>and you want to extend your storage by adding two disks: da2 and da3: > >> > >> # umount /foo > >> # gconcat stop foo > >> # gconcat label foo da0 da1 da2 da3 > >> # growfs /dev/concat/foo > >> # mount /dev/concat/foo /foo > >> > >>That's all. > >> > >>You can operate on mirrors too: > >> > >> # gmirror label foo0 da0 da1 > >> # gconcat label foo mirror/foo0 > >> # newfs /dev/concat/foo > >> # mount /dev/concat/foo /foo > >> > >>And extending: > >> > >> # gmirror label foo1 da2 da3 > >> # umount /foo > >> # gconcat stop foo > >> # gconcat label foo mirror/foo0 mirror/foo1 > >> # growfs /dev/concat/foo > >> # mount /dev/concat/foo /foo > >yes, this was the trivial part, but: > >1) to increment them, i need a device(disk/slice/label/etc). > >if i increment a lot, i need a lot of devices. > >2) these incrementum-devices (the ones i increment by), > >have to be made, each of the has to be chopped from the > >storage pool. > >please also look at the bsdlabel issue i have mentioned. > >gconcating is the most easy part of that. recursively > >bsdlabeling is what i have mostly referred to as the > >real issue. i really don't think this is the way to > >do it... > >if you are down to the bits: we are running our systems > >on 3ware cards. the end of the disk (usually total-20G) is > >the storage pool. under linux's LVM2 we use this as a pool > >to allocate space for our services. At the startup only > >a minimal part of the pool is used, and as a service needs > >more space, we enlarge its available space, by little increments. > >so, we are not adding new disks, or anything, as you have assumed > >in your upper examples. we just give it a bit more space, nothing > >special. > >new disks are not being added, that's why i had said "storage pool", > >to reflect this situation. it wasn't just a term for an abstraction > >level :) >=20 >=20 > I really think gvirstor is a good fit for you. Search this list for some= info on it, or just play=20 > with it a bit. The author is active on this list and so he'll probably p= ipe up. Thank you very much. I will check it out soonly. I've got two more questions: Is there a patch for the 6-STABLE tree? Will it be available in 7.0-RELEASE? Bye, Gergely Czuczy mailto: gergely.czuczy@harmless.hu --=20 Weenies test. Geniuses solve problems that arise. --Nq2Wo0NMKNjxTN9z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) owGtV8+PHEcVdhKBlBYI5YYgh5fksF4yP3pmvd7xgHfZ2JvFyEssdsGKOUQ13TUz xXRXtauqZ3Zy4cKBA0iIG+JAUM5IHODMXwD/Agf+BIg4wvequmdnbZwckstouuu9 V9/79b3Xv/7qKzdefu3vf/rzT97+5W9+99Ifv/bx5Ftl7b2edUthl0p3B2k66I5G t4eD7u3u7f29fHQwvSPlwWBf7L37jQ9O7xntpfbdi3Ulx+Tlpe9XhVD625TNhXXS 3639tDtKWrn7ylXGKa+MHpPShdJyc3ZhhXZTabsnOjO50rMxPa2Nl3m3skp7MSlk kryn6czoDh1XltI7HRqm6QEJT4N0fGsw3h8dn1E33U/TDp1YldGxzqV1RtPKwtI4 OSQYSG/10zt96EFpb9ihU2lnsljTvSc/uvfk/SvRwxddlu6Ph7fG6eDRGb2dDvmy R2IlC/q+WNQTui9WKpeLLTsvNnRrvDcaD0ZXhl6I5VOM3BkPR+O9/c90/TAaYfdH wf298f5BB3hn3ROLVMzovDw6sjMrlteVDp9B9Z1qbmSpLr+LHJeFdK43rw+horx0 G53DtRRVhxQttFmRmJja05N3zzskHF4K5+pS4tjTShUFaSlzEtbUOqdBb787JKhb tzE2taYkGOrQai41HfTS7g9PHp4cn59E/YkkK0W+7rUaPzBsfMeRvKxkhioiP1eO pqIoNjKHArepnZIKYxbs/9RYEuRMUXOFNo+VNXmdhRdSL5U1ukS54loY1FemAuCN 6Yu5tJJwoTZkPB42VluR722iMsuMzoQ/Inrf1JSZusgpgzde4vZSWWtsB+jhdiNJ Qkeb5d2kOZY+w88lGok7h6XvDtPmptOT9856RBdswdawYs1q6gj++DmMRS0EaAmE pYTkY4agd3w8Xxm7OIqmVvM1zSKiow0YZ0o5hzMROBJROxjj2HHEO1FzUvv4Z7CL 7DspOTDCe5HNyVTSik3AW7Me53kelZCCpeJyjqAlTYs208PdmNhVuN3Kp7VC4Fm5 WIm1awPp6kklrA/M4/oTlxdiIoumvhqjuXILlCdqAhcj9BMUZ2lgDedcn/HG8wK+ 5malx7v0oKwKydXAMTfTaZcJjXaiXztbjgGgt2qpRMH2gx2jP01aFM6QFG7dIYQO Uc0EwkprFEhoFThY6xLtEsM6VQV8XDsvS1ywhuedKzxNmGHVLKIP4eeh5PaIjRgM z8VSUlZbC4fQ7H5lQkjcmHKRhrjkYrBl4NW3NskK0UT6TBCFWCugJZdaP5fLfhTt Q6g9DPifPaSNRPjhaxncSuhQE7Fa+RVayhsrZpIma85YqPttzMMG8974Gua6uXYL yKaUvano/7x/zr1gHZY3grGlPoefF2g1TkdLT+En8IHQTWmEQozdh3Iy5rpbTV9e YU2fzcXz3kQVBpJ+YQnD3Lkios+A+FwcP1dutrzZ+j/4InK0lq7T8AzGF5NF287M KqFHg6tgN9So0mCdMCQgWfIMjOONYF1l8iZXaN8V+NsP6Ptg792QdjWF8JW6wGTy W/p4Qls3ZlzQCPwnQQ0brbrsNgJ0k5EaLd01q5P1bmDl0O+AC8ouRY5hLAMbT4N/ c/YznGVzU1XM6DyCccSqbedVxsR6BQ8KgAi0xdOUFxM20zIt2MfVABlJJlAmcEVK bTLJ/aticEvjfGC/EN4ISfge6B305NQSuwgrtsYbzRVPq/YGWACHWYmF0ka+jIlj PYyEBlAP8vwE0dzEiaf0Ima6wQIuhTar5cis7/XaRDErCUwHngVsP7irPKhnJcMB Zq0Og4GpKnBzmDdo4r0Vn2fC5q4X9JjSmsBzcdDN2tUBlTdeFN1heoqxGbRZ5Fr0 MQcwGQlBqC9BIA9/fDZkADwtghtwWwTJoM1zsTBZGImVyGQYuQGgtLGo6DhmznmE vq5QPjHYvIpoVTYl36JlwxwpnvnN7OT7GmuhbgPsMEfDjR1GJ3UhsFIinpBeClXw dt+eg84L5X2xVdOx1p3ptLHFAtRyPhgrcj5GnuXpxzmchT1zM9XilAuDV+k4PGoU tQVTCZ7hcBuGf1qj7GYoL15Lt+Z/g4uXLlgOSLBTovsDqs39G2ATybgAj2PiI7Hz 6sS1mZMTKqc3t3P4ZqfJDcq1wLIaE4fPpDrsA72wJQvH9RkgCnxp2TKupxpLpPNW hAWVzRQS7UHj3eQwbIBxDXzQVnms7xnWWAYQNg2aGYPuxh1sELHBBniOXRZcEHAU ysUjXvTuJkjK1PAkUj4EPCDCR9863sRr8SZ8ceskUft5cxlgLmXc4lrTXDRgjbnc wR6PTW+CWkDjY7WtUMZVL8FoBGbO5VLaNZV1Nu/Bo7D3Z3OZLfg+XqSd4WLtJcmD HVwyQyZ4HwgpfFpLF3a/cfIg9LXl5boSHl7GVVXS7e75xfE7D0/A7VIeJY/ZvuJs bpWouvbtcZQk76xlJ0k2H0gf1tmH66SEuDdjmsXXvSy83v5cSpJulwP2WEqtwM/4 ckK0TvGATnL8sQAPOBjYL13cw4VVTvaSXxy98qUb/O3dfre/9vL66zc++vnrv73/ qnrrv1/567/++cnf/vLJ/Z8Vv7rx+9xMv7n4+KOX6PV//Od8+oebj778xr//Bw== =dbY4 -----END PGP SIGNATURE----- --Nq2Wo0NMKNjxTN9z-- From owner-freebsd-geom@FreeBSD.ORG Tue Apr 10 07:17:15 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B8D3716A402; Tue, 10 Apr 2007 07:17:15 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.freebsd.org (Postfix) with ESMTP id 81C6713C45A; Tue, 10 Apr 2007 07:17:14 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id 323244329A; Tue, 10 Apr 2007 09:17:14 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 70E9E9C387; Tue, 10 Apr 2007 07:17:05 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 3A620405B; Tue, 10 Apr 2007 09:17:05 +0200 (CEST) Date: Tue, 10 Apr 2007 09:17:05 +0200 From: Jeremie Le Hen To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20070410071704.GB2102@obiwan.tataz.chchile.org> References: <20070408140215.GA54201@harmless.hu> <86k5wmu420.fsf@dwp.des.no> <461A4DDC.2090307@freebsd.org> <86odlxeeqt.fsf@dwp.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86odlxeeqt.fsf@dwp.des.no> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-geom@freebsd.org Subject: Re: volume management 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, 10 Apr 2007 07:17:15 -0000 Hi, Dag-Erling, Eric, On Mon, Apr 09, 2007 at 05:42:18PM +0200, Dag-Erling Smørgrav wrote: > Eric Anderson writes: > > On 04/08/07 13:14, Dag-Erling Smørgrav wrote: > > > ZFS in -CURRENT does that and more. I also have unfinished code for a > > > GEOM-based LVM, but none of FreeBSD's file systems support on-the-fly > > > resizing, so ZFS is really your best option. > > Is that code available in P4 somewhere (or elsewhere)? Sounds > > interesting. > > There's a patch in . > It's quite old, though. The file system that held my glvm tree > crashed, so it only exists as a compressed dump right now. I'll try > to get it back from the dead tomorrow, and possibly stick it in p4. Is there any difference between "glvm" and gvirstor ? I suppose there are at least a few, but what are them ? Thank you for this work at any rate, this feature is really lacking! Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-geom@FreeBSD.ORG Tue Apr 10 09:21:03 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1E81C16A404; Tue, 10 Apr 2007 09:21:03 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id D721113C468; Tue, 10 Apr 2007 09:21:02 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id D0EBB2091; Tue, 10 Apr 2007 11:20:58 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id B05FB2090; Tue, 10 Apr 2007 11:20:58 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id F0E78A1089; Tue, 10 Apr 2007 11:20:57 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Jeremie Le Hen References: <20070408140215.GA54201@harmless.hu> <86k5wmu420.fsf@dwp.des.no> <461A4DDC.2090307@freebsd.org> <86odlxeeqt.fsf@dwp.des.no> <20070410071704.GB2102@obiwan.tataz.chchile.org> Date: Tue, 10 Apr 2007 11:20:57 +0200 Message-ID: <861wis4mbq.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-geom@freebsd.org Subject: Re: volume management 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, 10 Apr 2007 09:21:03 -0000 Jeremie Le Hen writes: > Is there any difference between "glvm" and gvirstor ? I suppose there > are at least a few, but what are them ? gvirstor is a kind of "virtual memory" for disks - you pre-allocate address space and worry later about where to find physical space to back it. glvm works the other way around - you have a certain amount of physical space and manually allocate address space from it when you need it. glvm gives you flexibility without having to worry about over- committing your physical space; on the other hand, gvirstor can spare you the trouble of having to resize your file systems, but will be far more susceptible to fragmentation. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-geom@FreeBSD.ORG Tue Apr 10 11:03:52 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5A9BE16A400 for ; Tue, 10 Apr 2007 11:03:52 +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 DE2BB13C465 for ; Tue, 10 Apr 2007 11:03:51 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HbE8Q-0006ge-KZ for freebsd-geom@freebsd.org; Tue, 10 Apr 2007 13:03:38 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Apr 2007 13:03:38 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Apr 2007 13:03:38 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Tue, 10 Apr 2007 13:03:18 +0200 Lines: 45 Message-ID: References: <20070408140215.GA54201@harmless.hu> <86k5wmu420.fsf@dwp.des.no> <20070408181916.GA59715@harmless.hu> <86bqhyu225.fsf@dwp.des.no> <461A4D93.3010200@freebsd.org> <20070409143818.GA86722@harmless.hu> <20070409152401.GG76673@garage.freebsd.pl> <20070409153203.GA88082@harmless.hu> <461A5EC6.8010000@freebsd.org> <20070409154407.GA88621@harmless.hu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6BD51A42A3F299D9E3BF967C" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.10 (X11/20060911) In-Reply-To: <20070409154407.GA88621@harmless.hu> X-Enigmail-Version: 0.94.2.0 Sender: news Subject: Re: volume management 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, 10 Apr 2007 11:03:52 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6BD51A42A3F299D9E3BF967C Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Gergely CZUCZY wrote: >> I really think gvirstor is a good fit for you. Search this list for s= ome info on it, or just play=20 >> with it a bit. The author is active on this list and so he'll probabl= y pipe up. Yes, as soon as I decide what to do when physical space runs out, it=20 will be done. (the current problem is: if I return ENOSPC or EIO to UFS, = UFS will panic or get hopelessly confused). > Thank you very much. I will check it out soonly. >=20 > I've got two more questions: > Is there a patch for the 6-STABLE tree? Yes, the code should work on both 6-STABLE and 7-CURRENT. See=20 http://wiki.freebsd.org/gvirstor for details. > Will it be available in 7.0-RELEASE? Yes. --------------enig6BD51A42A3F299D9E3BF967C 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.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGG279ldnAQVacBcgRAjS5AJ9lXo0ughAOb41dzBFUPftqIf+ECwCg6uTv 8D/AiqGNLJ0+odYPlXcx30g= =i2YF -----END PGP SIGNATURE----- --------------enig6BD51A42A3F299D9E3BF967C-- From owner-freebsd-geom@FreeBSD.ORG Tue Apr 10 11:09:14 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2905116A401 for ; Tue, 10 Apr 2007 11:09:14 +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 AD38F13C459 for ; Tue, 10 Apr 2007 11:09:13 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HbEDb-0007Xn-U2 for freebsd-geom@freebsd.org; Tue, 10 Apr 2007 13:09:00 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Apr 2007 13:08:59 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Apr 2007 13:08:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Tue, 10 Apr 2007 13:08:50 +0200 Lines: 46 Message-ID: References: <20070408140215.GA54201@harmless.hu> <86k5wmu420.fsf@dwp.des.no> <20070408181916.GA59715@harmless.hu> <86bqhyu225.fsf@dwp.des.no> <461A4D93.3010200@freebsd.org> <20070409143818.GA86722@harmless.hu> <20070409152401.GG76673@garage.freebsd.pl> <20070409153203.GA88082@harmless.hu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0D93EB2358698E2E83D0D175" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.10 (X11/20060911) In-Reply-To: <20070409153203.GA88082@harmless.hu> X-Enigmail-Version: 0.94.2.0 Sender: news Subject: Re: volume management 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, 10 Apr 2007 11:09:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0D93EB2358698E2E83D0D175 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Gergely CZUCZY wrote: > 1) to increment them, i need a device(disk/slice/label/etc). > if i increment a lot, i need a lot of devices. Are you concerned about the number of entries in the /dev file system? Wh= y? > 2) these incrementum-devices (the ones i increment by), > have to be made, each of the has to be chopped from the > storage pool. The whole GEOM tree is your storage pool. > please also look at the bsdlabel issue i have mentioned. > gconcating is the most easy part of that. recursively > bsdlabeling is what i have mostly referred to as the > real issue. i really don't think this is the way to > do it... If I understood you correctly, your problem is that you don't want to=20 use entire drives for extending your file systems, but only parts of=20 them, right? --------------enig0D93EB2358698E2E83D0D175 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.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGG3BCldnAQVacBcgRAqdDAJ9ZSaNEqXOtnuTVg5WxsUp3o+r3HwCfSpTD KqyH81Jn7uJXONd5m2zh/4A= =bEdg -----END PGP SIGNATURE----- --------------enig0D93EB2358698E2E83D0D175-- From owner-freebsd-geom@FreeBSD.ORG Tue Apr 10 11:10:08 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 29BB416A404 for ; Tue, 10 Apr 2007 11:10:08 +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 D786113C457 for ; Tue, 10 Apr 2007 11:10:07 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1HbEEc-0007iW-Ru for freebsd-geom@freebsd.org; Tue, 10 Apr 2007 13:10:03 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Apr 2007 13:10:02 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Apr 2007 13:10:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Tue, 10 Apr 2007 13:06:36 +0200 Lines: 40 Message-ID: References: <20070408140215.GA54201@harmless.hu> <86k5wmu420.fsf@dwp.des.no> <20070408181916.GA59715@harmless.hu> <86bqhyu225.fsf@dwp.des.no> <461A4D93.3010200@freebsd.org> <20070409143818.GA86722@harmless.hu> <461A5812.1080205@freebsd.org> <20070409151902.GA87807@harmless.hu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig876DFA2876AC3946199387A7" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.10 (X11/20060911) In-Reply-To: <20070409151902.GA87807@harmless.hu> X-Enigmail-Version: 0.94.2.0 Sender: news Subject: Re: volume management 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, 10 Apr 2007 11:10:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig876DFA2876AC3946199387A7 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Gergely CZUCZY wrote: >> >> http://wiki.freebsd.org/gvirstor > similar, yes. but this wiki page is quite foggy on exactly how > does gvirstor works, what can it do, how does it do that, and > so on. even the provided example is a bit undecryptable, and without > any comments (that screenshot). i've checked this previously, and > wasn't able to decide whether i need this or not. Ok, so what information do you think should be on that page to make it=20 more usable? > and also, there wasn't any remarks on the tarballs to what > to do with them, and for which branch were they made for. There's the instruction to read the README file... --------------enig876DFA2876AC3946199387A7 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.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGG2+8ldnAQVacBcgRAon3AJ9CgQCKCbg9i4rp4+6SDDeedm0uCACeNicN D/N0EyEPcj24RiRSmKdRmFs= =WwUv -----END PGP SIGNATURE----- --------------enig876DFA2876AC3946199387A7-- From owner-freebsd-geom@FreeBSD.ORG Tue Apr 10 11:20:12 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1BB4216A401 for ; Tue, 10 Apr 2007 11:20:12 +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 A726113C48A for ; Tue, 10 Apr 2007 11:20:11 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 3FECD487FD; Tue, 10 Apr 2007 13:20:09 +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 D3FA6456B1; Tue, 10 Apr 2007 13:20:04 +0200 (CEST) Date: Tue, 10 Apr 2007 13:19:57 +0200 From: Pawel Jakub Dawidek To: Ivan Voras Message-ID: <20070410111957.GA85578@garage.freebsd.pl> References: <86k5wmu420.fsf@dwp.des.no> <20070408181916.GA59715@harmless.hu> <86bqhyu225.fsf@dwp.des.no> <461A4D93.3010200@freebsd.org> <20070409143818.GA86722@harmless.hu> <20070409152401.GG76673@garage.freebsd.pl> <20070409153203.GA88082@harmless.hu> <461A5EC6.8010000@freebsd.org> <20070409154407.GA88621@harmless.hu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline In-Reply-To: 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@freebsd.org Subject: Re: volume management 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, 10 Apr 2007 11:20:12 -0000 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 10, 2007 at 01:03:18PM +0200, Ivan Voras wrote: > Gergely CZUCZY wrote: >=20 > >>I really think gvirstor is a good fit for you. Search this list for so= me info on it, or just play with it a bit. The author is active on this li= st and so he'll probably=20 > >>pipe up. >=20 > Yes, as soon as I decide what to do when physical space runs out, it will= be done. (the current problem is: if I return ENOSPC or EIO to UFS, UFS wi= ll panic or get=20 > hopelessly confused). Ivan, as you probably already find out this is not an easy task and it gets more complex when SU comes into play or any async operations, because there is noone waiting for the error to return. Maybe you for now allow to set two modes of handling ENOSPC (configurable by the user): 1. Panic if there is no physical storage. This way you protect consistency. You already printed a warning that gvirstor is running out of physical storage, so administrator has a chance to do the job. 2. Hang until the storage is available. Just don't return from I/O until new provider is attached to gvirstor. You may want to leave 3rd option to just return ENOSPC, because besides UFS there can be other gvirstor consumers that handle errors more properly. You may also want to consider sending warnings to devd, which I do in ZFS (see zfs_fm.c and devd.conf) and should do in others GEOM classes. This way administrator can configure sending an e-mail when gvristor is running out of storage. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGG3LdForvXbEpPzQRAj7fAJ9NwCSbwTldEIZ6za6tulr5Tkt5WACgnCU/ oK4XFpYBrpG2vYYp5q33qTg= =dsuq -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- From owner-freebsd-geom@FreeBSD.ORG Tue Apr 10 11:32:06 2007 Return-Path: X-Original-To: freebsd-geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 000D816A405; Tue, 10 Apr 2007 11:32:05 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from pinus.cc.fer.hr (pinus.cc.fer.hr [161.53.73.18]) by mx1.freebsd.org (Postfix) with ESMTP id 7349E13C4CB; Tue, 10 Apr 2007 11:32:05 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from [161.53.72.113] (lara.cc.fer.hr [161.53.72.113]) by pinus.cc.fer.hr (8.12.2/8.12.2) with ESMTP id l3ABeRLT018511; Tue, 10 Apr 2007 13:40:27 +0200 (MEST) Message-ID: <461B75B2.40201@fer.hr> Date: Tue, 10 Apr 2007 13:32:02 +0200 From: Ivan Voras User-Agent: Thunderbird 1.5.0.10 (X11/20060911) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <86k5wmu420.fsf@dwp.des.no> <20070408181916.GA59715@harmless.hu> <86bqhyu225.fsf@dwp.des.no> <461A4D93.3010200@freebsd.org> <20070409143818.GA86722@harmless.hu> <20070409152401.GG76673@garage.freebsd.pl> <20070409153203.GA88082@harmless.hu> <461A5EC6.8010000@freebsd.org> <20070409154407.GA88621@harmless.hu> <20070410111957.GA85578@garage.freebsd.pl> In-Reply-To: <20070410111957.GA85578@garage.freebsd.pl> X-Enigmail-Version: 0.94.2.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig86A1C9198CED72F57BA0784C" Cc: freebsd-geom@FreeBSD.org Subject: Re: volume management 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, 10 Apr 2007 11:32:06 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig86A1C9198CED72F57BA0784C Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Pawel Jakub Dawidek wrote: > Ivan, as you probably already find out this is not an easy task and it > gets more complex when SU comes into play or any async operations, > because there is noone waiting for the error to return. >=20 > Maybe you for now allow to set two modes of handling ENOSPC > (configurable by the user): > 1. Panic if there is no physical storage. This way you protect > consistency. You already printed a warning that gvirstor is running > out of physical storage, so administrator has a chance to do the job= =2E I really don't want to do that :( > 2. Hang until the storage is available. Just don't return from I/O unti= l > new provider is attached to gvirstor. I'd rather do this. I'm still worried about the possibility some=20 unexpected softupdates timer will to the wrong thing here, but I'll try i= t. > You may want to leave 3rd option to just return ENOSPC, because besides= > UFS there can be other gvirstor consumers that handle errors more > properly. Ok. > You may also want to consider sending warnings to devd, which I do in > ZFS (see zfs_fm.c and devd.conf) and should do in others GEOM classes. > This way administrator can configure sending an e-mail when gvristor is= > running out of storage. Good idea, I'll look it up. --------------enig86A1C9198CED72F57BA0784C 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.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGG3WyldnAQVacBcgRAkyVAJ9V2+l3Spme+iYaahjdl1bagZkhrQCffZiE QPkcb9BQAhPaLLcLfoz0q+4= =hMkj -----END PGP SIGNATURE----- --------------enig86A1C9198CED72F57BA0784C-- From owner-freebsd-geom@FreeBSD.ORG Tue Apr 10 11:37:05 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0754016A405 for ; Tue, 10 Apr 2007 11:37:05 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) by mx1.freebsd.org (Postfix) with ESMTP id 7124713C45A for ; Tue, 10 Apr 2007 11:37:04 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from localhost (marvin-mail [192.168.0.2]) by marvin.harmless.hu (Postfix) with ESMTP id 4F5D47C0C2B; Tue, 10 Apr 2007 13:37:03 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.4.2 (20060627) (Debian) at harmless.hu Received: from marvin.harmless.hu ([192.168.0.2]) by localhost (marvin.harmless.hu [192.168.0.2]) (amavisd-new, port 10024) with ESMTP id IMVC95b1a5kq; Tue, 10 Apr 2007 13:37:03 +0200 (CEST) Received: from marvin.harmless.hu (localhost [127.0.0.1]) by marvin.harmless.hu (Postfix) with ESMTP id D20DB7C0C2A; Tue, 10 Apr 2007 13:37:02 +0200 (CEST) Date: Tue, 10 Apr 2007 13:37:02 +0200 From: Gergely CZUCZY To: Ivan Voras Message-ID: <20070410113702.GA17344@harmless.hu> References: <20070408140215.GA54201@harmless.hu> <86k5wmu420.fsf@dwp.des.no> <20070408181916.GA59715@harmless.hu> <86bqhyu225.fsf@dwp.des.no> <461A4D93.3010200@freebsd.org> <20070409143818.GA86722@harmless.hu> <20070409152401.GG76673@garage.freebsd.pl> <20070409153203.GA88082@harmless.hu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline In-Reply-To: User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: freebsd-geom@freebsd.org Subject: Re: volume management 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, 10 Apr 2007 11:37:05 -0000 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment Content-Transfer-Encoding: quoted-printable On Tue, Apr 10, 2007 at 01:08:50PM +0200, Ivan Voras wrote: > Gergely CZUCZY wrote: >=20 > >1) to increment them, i need a device(disk/slice/label/etc). > >if i increment a lot, i need a lot of devices. >=20 > Are you concerned about the number of entries in the /dev file system? Wh= y? >=20 > >2) these incrementum-devices (the ones i increment by), > >have to be made, each of the has to be chopped from the > >storage pool. >=20 > The whole GEOM tree is your storage pool. > > >please also look at the bsdlabel issue i have mentioned. > >gconcating is the most easy part of that. recursively > >bsdlabeling is what i have mostly referred to as the > >real issue. i really don't think this is the way to > >do it... >=20 > If I understood you correctly, your problem is that you don't want to use= entire drives for=20 > extending your file systems, but only parts of them, right? The mot accurate description would be the functionality of linux's LVM in the scope of volume management, that's why i had given this subject to this email/topic. I have a storage pool (the last part of a disk), from which i want to chop little pieces for services, and i want to be able to increment these little pieces whenever needed. Like i have a pool of 100G. i have two services, i allocate 10G and 20G for them. 30G is used. Upon need, i allocate a bit more first to service1, then it will have 15G of space available. After this, the other one might need a bit more space, so i give it a bit more, let's say 8G, and it will have 28G of space. It's really what i have described here several times. Having a storage pool, from which volume management can be done. Dynamic allication of storage areas from the same pool, and having the abilit to increase the size of the previously allocated storage areas when it's needed. It's kinda like what's Linux's LVM's main feature. And i'm a bit surprised that FreeBSD doesn't have a similar thing. I have read the README of gvirstor and looked around in the source tree of it. It seems like me, that gvirstor is a bit different then what I need. It allows me to overrun the available physical space, while i need to be able to increment the storage's availabe size when it's needed. Farthermore as I have seen gvirstor only provides one storage area =66rom a given provider, and what I need is many provided storage areas =66rom the very same pool. Bye, Gergely Czuczy mailto: gergely.czuczy@harmless.hu --=20 Weenies test. Geniuses solve problems that arise. --4Ckj6UjgE2iN1+kY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) owFtls1uHEUQx02iINQSQjlx4FKcHCu7610ndiwjxzixYyzFCiJOAgGk9Mz07jae 6Z509+xm8gJEiANCSBwAKQ8AEhIoFw68AY8AEuLEESFx5V/zsbsmXJzsTNfXv35V PZ+9fHbpzPlfvv/x/Yuffv7VC9+JPOpkRQhm1M2km2jTHfT7g+7gyqXLl7uDje7a Rj+KBirZWF/vD9cH8sZrk1+vWxOUCd3jMldbFNSjsJqnUps3KB5L51XYLsKwuyna c3va59broK3ZIhmCjMcZns/eHztp/FC57r6JbaLNaIseFjaopJs7bYKMUiXELUPH herQbu5o0O/QWr9/Bc6oP9jqb26t998+oot9POzQ4UQaumud9DR1cLMlrtKBciOV lnT9/p3r99+bPd9e6+Pl1cEKBUvaxE5xYhTGKuuQJqNUQpISNdGxupBof7LqU/x3 NZWRSldViFd6bK+HODw3l5TasGCPX2SHjRvfa8PuOkWlLSi2JlbO8NHIFlV0MkUW KcdWcOi08nBfvViFFxrqVJEvfVDZDt0bb4tyZ1bL2gqf82qeT5F1m9B0gV1Yw+4W 8o3KlQ6bjuVEsRCRokwm0FqhU5wDW40hZ/0uHts8R7ZDZzN+xaY+QO+RotzadFbg McymY4tcD/ZvHVFwCll5rtnRfwzYR54qibxl6i0ksyfcXY4c+aTSG7a+gAeq8uTM AZRKqg6MWEQZwA5HYKvM+oACfEm5dKGuQoYeORUXzusJaGDD1nljOcWZWQR4ADJO AU2HelG99G3BTskmoR7O8y8cTaxZ5py1OeG/vs1lKktYs1kCzEKvN5PocEiHVJhE OQhik4YHhIsRulNLlTuLCchqZ0iPz9SRppJhtVR4tS2YFA2kEofiPA2tq0NgPJXh qaq9LbDjOxSBN2vSWiTf9BrsOz0ahx1xXAkJomOIJgOcKx87nbPyNLVFmjAQXOKw MDE/lakOpYAfKFo8WvZ08+5Ry66Pba44xsSmRcaQGSDAjexUlS2z/qVg+RMaoQpT q+iL6CMIwpVWv1UmdboabK7jnhCHdbfkKaRq0lMJBtr2Y44xwCudmtvpWMdjhGol ZKiRcwhQJ9cqrhUkr1w1OR2SJqH58UgJXkvPrQ3we9rJdKyMmmCUeRcwrOKmPplB LOtkkR227kGvfRymdiGyxkikFnQrMegfVIms4V9Oj5vVo0v4BVlAQdKjOzlaw8EW DREo0kFkFnwMNVjjxJsIAxYfUmvwpNO0zmCwfsBZ+VzGqHQCvbncHu0Og3JVFyor svjjeKNQxsS0Gw/BiIOJykGHMNG66ihHmb/uUKq46x7zsXnQaFynIao01jbnaXCr +XAza4uTWlMZITSyAWcsOMYz6Azrlt6SuNZG4jQgixg8zyPFuEJANsYMRe+VRmY6 FoireclAYE6q8SaRkJ8tQ9SStRG4nHEVvNoaMtJgY4YM77rKQD9W7ZLNHRa1LTzq a1uXtIFEHWha9wpCNERRpcqJNgluGmZrWo/SzfkALnuBkTE0VDIUjtvIQi9nTSt8 4XDRel5xLOoN7Olrt/dQvPLYMqIdL52Bgqr5ZjSfOySVVLm/s7+7d7TPlYwmjBjw ZAF4kzMTzhYctNkE2EQAq7oRYICViCrQN+ykuoZM1Sth7guA19kmeoiFzN8PFbYV B4eVGJUT1m3q4YCFtgDBFXXMGcWUj0uPRqYtnYAgVe11Xd9x/zvcbScgauMMgHP3 nuuJEDewdQBjNXHoWiMWKjTzkurF6+xEA+BqiBaZEtsbGwyVbFZhc9DVXC2UzdIA 3Zmr5DSarR8uAHKUc0KRphDXStURYvZ99LiIH5dMSxrsFo3qx724evwmvu6yVHnf GxdCdLt8v9xDRfx5EpRHEw/wA2sIE23TiWpvrubeksxYTzzZOXtuiT8j24/Q82c+ eLj09JM/H+x8/OzZD9Off/ry2j/L3+789u7rS0+f5B9+PTn30l+vpK/e/uL3v1/8 4xu7+y8= =7yeW -----END PGP SIGNATURE----- --4Ckj6UjgE2iN1+kY-- From owner-freebsd-geom@FreeBSD.ORG Tue Apr 10 11:41:30 2007 Return-Path: X-Original-To: freebsd-geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8AB2E16A400 for ; Tue, 10 Apr 2007 11:41:30 +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 21F6413C4C6 for ; Tue, 10 Apr 2007 11:41:30 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 8581D48804; Tue, 10 Apr 2007 13:41:28 +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 686CB487F2; Tue, 10 Apr 2007 13:41:23 +0200 (CEST) Date: Tue, 10 Apr 2007 13:41:15 +0200 From: Pawel Jakub Dawidek To: Ivan Voras Message-ID: <20070410114115.GB85578@garage.freebsd.pl> References: <86bqhyu225.fsf@dwp.des.no> <461A4D93.3010200@freebsd.org> <20070409143818.GA86722@harmless.hu> <20070409152401.GG76673@garage.freebsd.pl> <20070409153203.GA88082@harmless.hu> <461A5EC6.8010000@freebsd.org> <20070409154407.GA88621@harmless.hu> <20070410111957.GA85578@garage.freebsd.pl> <461B75B2.40201@fer.hr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FkmkrVfFsRoUs1wW" Content-Disposition: inline In-Reply-To: <461B75B2.40201@fer.hr> 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@FreeBSD.org Subject: Re: volume management 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, 10 Apr 2007 11:41:30 -0000 --FkmkrVfFsRoUs1wW Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 10, 2007 at 01:32:02PM +0200, Ivan Voras wrote: > Pawel Jakub Dawidek wrote: >=20 > >Ivan, as you probably already find out this is not an easy task and it > >gets more complex when SU comes into play or any async operations, > >because there is noone waiting for the error to return. > >Maybe you for now allow to set two modes of handling ENOSPC > >(configurable by the user): > >1. Panic if there is no physical storage. This way you protect > > consistency. You already printed a warning that gvirstor is running > > out of physical storage, so administrator has a chance to do the job. >=20 > I really don't want to do that :( If you have important data, this is really not bad idea. I, for one, prefer my kernel to panic, so I can see what exactly went wrong, add another disk and reboot instead of allowing kernel goes into wild by returning an error which won't be handled properly. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --FkmkrVfFsRoUs1wW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGG3fbForvXbEpPzQRAn1EAKDt35KTQnY3YBKKj7X9zuUxsuMFWgCgz/UE 0Bp+f/3QQ02Cw8RZew6wQ0c= =7Y+i -----END PGP SIGNATURE----- --FkmkrVfFsRoUs1wW-- From owner-freebsd-geom@FreeBSD.ORG Tue Apr 10 11:58:47 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B063116A4F4 for ; Tue, 10 Apr 2007 11:58:47 +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 07E9713C4F2 for ; Tue, 10 Apr 2007 11:58:46 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 459F8487FD; Tue, 10 Apr 2007 13:58:45 +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 BE76045683; Tue, 10 Apr 2007 13:58:40 +0200 (CEST) Date: Tue, 10 Apr 2007 13:58:33 +0200 From: Pawel Jakub Dawidek To: Gergely CZUCZY Message-ID: <20070410115833.GC85578@garage.freebsd.pl> References: <20070408140215.GA54201@harmless.hu> <86k5wmu420.fsf@dwp.des.no> <20070408181916.GA59715@harmless.hu> <86bqhyu225.fsf@dwp.des.no> <461A4D93.3010200@freebsd.org> <20070409143818.GA86722@harmless.hu> <20070409152401.GG76673@garage.freebsd.pl> <20070409153203.GA88082@harmless.hu> <20070410113702.GA17344@harmless.hu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dkEUBIird37B8yKS" Content-Disposition: inline In-Reply-To: <20070410113702.GA17344@harmless.hu> 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: Ivan Voras , freebsd-geom@freebsd.org Subject: Re: volume management 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, 10 Apr 2007 11:58:47 -0000 --dkEUBIird37B8yKS Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 10, 2007 at 01:37:02PM +0200, Gergely CZUCZY wrote: > The mot accurate description would be the functionality > of linux's LVM in the scope of volume management, that's why > i had given this subject to this email/topic. >=20 > I have a storage pool (the last part of a disk), from which > i want to chop little pieces for services, and i want to be > able to increment these little pieces whenever needed. >=20 > Like i have a pool of 100G. i have two services, i allocate > 10G and 20G for them. 30G is used. Upon need, i allocate a bit > more first to service1, then it will have 15G of space > available. After this, the other one might need a bit more > space, so i give it a bit more, let's say 8G, and it will > have 28G of space. >=20 > It's really what i have described here several times. Having > a storage pool, from which volume management can be done. Dynamic > allication of storage areas from the same pool, and having the > abilit to increase the size of the previously allocated storage > areas when it's needed. It's kinda like what's Linux's LVM's > main feature. And i'm a bit surprised that FreeBSD doesn't > have a similar thing. Yeah... If you can afford running 7-CURRENT, you should really try ZFS. Even if you don't want to use ZFS file systems, you can still use ZFS ZVOLs and run UFS on top of them. For example: # zpool create tank mirror da0 da1 # zfs create -V 10g tank/foo # zfs create -V 20g tank/bar # diskinfo -v /dev/zvol/tank/{foo,bar} /dev/zvol/tank/foo 512 # sectorsize 10737418240 # mediasize in bytes (10G) 20971520 # mediasize in sectors /dev/zvol/tank/bar 512 # sectorsize 21474836480 # mediasize in bytes (20G) 41943040 # mediasize in sectors # newfs /dev/zvol/tank/foo # mount /dev/zvol/tank/foo /foo # newfs /dev/zvol/tank/bar # mount /dev/zvol/tank/bar /bar Now, when you want to grow tank/foo: # umount /foo # zfs set volsize=3D30g tank/foo # growfs /dev/zvol/tank/foo # mount /dev/zvol/tank/foo /foo Not to mention you have fast UFS snapshots, clones and other cool stuff:) The hardest part of ZFS was ZPL (ZFS POSIX Layer), which only comes into play for ZFS file systems and is not used when using ZVOLs. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --dkEUBIird37B8yKS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGG3vpForvXbEpPzQRAmJ1AKC79rCXXekqD5jmpcW7FqKJZWkIHwCgyxP4 TQBmw+4te/HxS0j/zHTjv3c= =itv/ -----END PGP SIGNATURE----- --dkEUBIird37B8yKS-- From owner-freebsd-geom@FreeBSD.ORG Tue Apr 10 12:03:29 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4321A16A401; Tue, 10 Apr 2007 12:03:29 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) by mx1.freebsd.org (Postfix) with ESMTP id 8E3CC13C468; Tue, 10 Apr 2007 12:03:28 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from localhost (marvin-mail [192.168.0.2]) by marvin.harmless.hu (Postfix) with ESMTP id A59547C0B9D; Tue, 10 Apr 2007 14:03:27 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.4.2 (20060627) (Debian) at harmless.hu Received: from marvin.harmless.hu ([192.168.0.2]) by localhost (marvin.harmless.hu [192.168.0.2]) (amavisd-new, port 10024) with ESMTP id CKS2v0-eTjCy; Tue, 10 Apr 2007 14:03:27 +0200 (CEST) Received: from marvin.harmless.hu (localhost [127.0.0.1]) by marvin.harmless.hu (Postfix) with ESMTP id 351957C0084; Tue, 10 Apr 2007 14:03:26 +0200 (CEST) Date: Tue, 10 Apr 2007 14:03:26 +0200 From: Gergely CZUCZY To: Pawel Jakub Dawidek Message-ID: <20070410120326.GA18218@harmless.hu> References: <86k5wmu420.fsf@dwp.des.no> <20070408181916.GA59715@harmless.hu> <86bqhyu225.fsf@dwp.des.no> <461A4D93.3010200@freebsd.org> <20070409143818.GA86722@harmless.hu> <20070409152401.GG76673@garage.freebsd.pl> <20070409153203.GA88082@harmless.hu> <20070410113702.GA17344@harmless.hu> <20070410115833.GC85578@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline In-Reply-To: <20070410115833.GC85578@garage.freebsd.pl> User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: freebsd-geom@freebsd.org Subject: Re: volume management 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, 10 Apr 2007 12:03:29 -0000 --AhhlLboLdkugWU4S Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 10, 2007 at 01:58:33PM +0200, Pawel Jakub Dawidek wrote: > On Tue, Apr 10, 2007 at 01:37:02PM +0200, Gergely CZUCZY wrote: > > The mot accurate description would be the functionality > > of linux's LVM in the scope of volume management, that's why > > i had given this subject to this email/topic. > >=20 > > I have a storage pool (the last part of a disk), from which > > i want to chop little pieces for services, and i want to be > > able to increment these little pieces whenever needed. > >=20 > > Like i have a pool of 100G. i have two services, i allocate > > 10G and 20G for them. 30G is used. Upon need, i allocate a bit > > more first to service1, then it will have 15G of space > > available. After this, the other one might need a bit more > > space, so i give it a bit more, let's say 8G, and it will > > have 28G of space. > >=20 > > It's really what i have described here several times. Having > > a storage pool, from which volume management can be done. Dynamic > > allication of storage areas from the same pool, and having the > > abilit to increase the size of the previously allocated storage > > areas when it's needed. It's kinda like what's Linux's LVM's > > main feature. And i'm a bit surprised that FreeBSD doesn't > > have a similar thing. >=20 > Yeah... If you can afford running 7-CURRENT, you should really try ZFS. > Even if you don't want to use ZFS file systems, you can still use ZFS > ZVOLs and run UFS on top of them. The fact is, i want to run this on a production box. Or, to be more precise, i will want to. Currently i'm thinking of awaiting of 7-STABLE, and testing the zfs layer there as much as possible to recover any relevant bugs, and hope that they get fixed till 7.0-RELEASE. I don't want to run -CURRENT, not even inhouse boxes, and especially not on production boxes, where we have to provide 99.9% I'm afraid of development code, sorry. I know FreeBSD's QA is great, but it's still development. > Not to mention you have fast UFS snapshots, clones and other cool > stuff:) Yes, i know this. I already use most of these things, incremental dumps, snapshots, restoring, so on. > The hardest part of ZFS was ZPL (ZFS POSIX Layer), which only comes into > play for ZFS file systems and is not used when using ZVOLs. I'd like to check it out in 7-STABLE as soon as it gets branched :) Bye, Gergely Czuczy mailto: gergely.czuczy@harmless.hu --=20 Weenies test. Geniuses solve problems that arise. --AhhlLboLdkugWU4S Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) owF9Vj1sHEUUNokQ0kpBRIoQUgoeEsiJsru5O8v2+VBCHNsxRpfYxHYgpkBzu7N3 w+3OLDOzt15L1FBQIAoaChANVUQQPyV0KBVINNRUFIgyPe/N7vnsINHYt7vv//ve N/PJubNzZ87/+vD7d658/OnnTz3wbgyuZIW1chhkTE+EDNqtVjtodzvtbrAUdLpL i0vRSmcpaXcXo5X2rYsfPLumpOXSBntVzntg+aG9mqdMyFchGjFtuL1W2CToelO7 dWFyZYQVSvZAyFRIfvxtTzNpEq6DDRmpWMhhD94vlOVxkGshLRuk3PO2JewV3IfV XEO75UOn1VoGZqHV7i12ewsLO7fhSgtf+rDDSp7CG2xcDGCdlSLmYyg1xut51+F/ wiws91qdWZhNroc8rWDtYH/t4P4swnXYG3HIlAUWRYVmlkPMTaRFTs1BqYo0hgEH i1ZJISN6y1JhK+erEsDei8N5A/17t3ESzs5EKuf0baLSIsPoTLIhz3A4Pn5nFq3L UR1AwIjFMBQTTq7CgCkG7/HIglX1M8+YSK9alYsoJI9rnZZz3ELHCQcGxiqN0SFX KoVLlD5lxkLOtKUSGMTCjC/7kGiVYVoRjZrEJZMuTTRSOXZhbYpBBI+4gURpMByp gw8+MBmfMB9w508w0qOQkXatUeeGPxGoHHHJJ1yD5Dzm8akO+mLMXf+uDVc+1otU 3Qynr22pTtQhgKWpihAi599ubbrSOvifCsb8WQgL+IRjKwxmg/0cIaTUJ50x2UBY FyJTGlEV2rjOmkxtAgnhEBZKkaZ1Je3FTarO5Cxq+p8gLjSEEFYTy7VDy3mCwj8a lETgxXBkXQF1UpfQubtAPhgcoEOfss1MfEg5scSwCrqbDQJ1Oc7bldTpzko6TQ1y 1Rz7rRAA3IZmmjWvB1gM1ocsJWBYClZk3ITwOkOlGNa9nSLVSer8l9EQMUn7EWO/ IaxXkmUiqqOkqcB50xZRmU1EhoWZOqJbFZZNs1CTI1cEfWlIJpBPxzRjpt5DI47c etHvXPOJUIXBXqcAx9NkdQyXsKwRxcE0TKynNBYyZshZZGJZL2Z/ts7zpiYJ6iAk nNlCE9gExXzWgGUKjaKGXHN7Dbc05zd313EY3Mh5O8MKJyoy5IujiRwiXDVY9zkb hSEWk0ClCjdLliCZY9CFlDSK5WBt/+7djTt7vrMwIydIDbpWV3Bwa5fQ3yAFEXUY xGLeHi8srgIZIc9xL01lLM+Mf5zOWOJ4Y4NxDu5t943DAiuAffRD/FB+mnlnoUd6 mTCUKOF2cpqGzJ1ioT2us1Zx4cQSBuowhG3t1+JRrwCiFuHYnD/lb4KEsFZojazC 3mjINKwxTYGErGR43tS/l4PdvdWb/Q3fo0ItN7ZhDRwlBvWvcvtIJEfoswJ5i//x wDKiUS1Mr5D96F7h75RPKP+gGDZqNyL9dohilAqG3OL0DgllKnY5bAV3N/obq7sb oedtPTFumsMMM4kHC3fQSEQOp4zTmGoqNzlOgYD0yAxHdXpqZFe6Lkre6KEikwme gbCyEq684m0RExPNRExjiTFTqvJ6LVXs9EXrCukFY6nKKT2R3W+ukkgOkUbW9waF rVej5sKJKNjedbijXF/0TIURcVwxCR0zRBAjWY68tFhulKIM1PSpVTDC1cYYxhZJ 0rvs3a913FVDZKHSWIplxJXjYKaMbZjmdh1hJYfpGYNqFRdZbnzvRE7Nad3R0smp kq5oIineXFDyZkchLUGJRDjY6cMletjZ3t16G/pEl8t+I3BKIvcihZKIaa3CUHgR qtwB8+QS1bJsHMZ03tQiUxjiolujEPGJa3Vx5yyPxiTjiuYtj0lM3DSKtsbQVySb gQHeodA+BpyZ592suO95xzeYoyI6qjy6F1jVQ3v3Oozc6xvYdJZyY8JR4XlBQDLz FudSYD+0JyFehKTAailnOiH9VLgT2IyjOyMxC72PXjv79BzdC6eXyvNnPnxp7gv7 96ML3z16GX568Ndn5y7+/OeLPz7zz9yX3/zy2+Mfvv369+3nX9h97uH4wr2v3v3j Xw== =kvR4 -----END PGP SIGNATURE----- --AhhlLboLdkugWU4S-- From owner-freebsd-geom@FreeBSD.ORG Tue Apr 10 16:14:46 2007 Return-Path: X-Original-To: freebsd-geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BA8A016A406 for ; Tue, 10 Apr 2007 16:14:46 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (keira.kiwi-computer.com [63.224.10.3]) by mx1.freebsd.org (Postfix) with SMTP id 4415113C468 for ; Tue, 10 Apr 2007 16:14:46 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: (qmail 19369 invoked by uid 2001); 10 Apr 2007 16:14:45 -0000 Date: Tue, 10 Apr 2007 11:14:45 -0500 From: "Rick C. Petty" To: Pawel Jakub Dawidek Message-ID: <20070410161445.GA18858@keira.kiwi-computer.com> References: <461A4D93.3010200@freebsd.org> <20070409143818.GA86722@harmless.hu> <20070409152401.GG76673@garage.freebsd.pl> <20070409153203.GA88082@harmless.hu> <461A5EC6.8010000@freebsd.org> <20070409154407.GA88621@harmless.hu> <20070410111957.GA85578@garage.freebsd.pl> <461B75B2.40201@fer.hr> <20070410114115.GB85578@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070410114115.GB85578@garage.freebsd.pl> User-Agent: Mutt/1.4.2.1i Cc: freebsd-geom@FreeBSD.org Subject: Re: volume management X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2007 16:14:46 -0000 On Tue, Apr 10, 2007 at 01:41:15PM +0200, Pawel Jakub Dawidek wrote: > On Tue, Apr 10, 2007 at 01:32:02PM +0200, Ivan Voras wrote: > > Pawel Jakub Dawidek wrote: > > > > >1. Panic if there is no physical storage. This way you protect > > > consistency. You already printed a warning that gvirstor is running > > > out of physical storage, so administrator has a chance to do the job. > > > > I really don't want to do that :( > > If you have important data, this is really not bad idea. I, for one, > prefer my kernel to panic, so I can see what exactly went wrong, add > another disk and reboot instead of allowing kernel goes into wild by > returning an error which won't be handled properly. It's a terrible idea! What happens to all uncommitted soft updates and other unwritten cached blocks? Lost forever, which can have bad effects on file systems and at the very least require everything to be fsck'd and GEOM mirrored or raid objects to be resync'd. What's wrong with ENOSPC? Isn't that the whole point of that error? Let the admin know that something failed, don't panic and prevent any further operation period. I know I don't want my fileserver to panic just because I accidently try to add 100 GB instead of 10 GB or some other simple miscalculation. We have enough panics in the kernel already for cases that should be handled better in userland. -- Rick C. Petty From owner-freebsd-geom@FreeBSD.ORG Tue Apr 10 16:21:52 2007 Return-Path: X-Original-To: freebsd-geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8549116A406 for ; Tue, 10 Apr 2007 16:21:52 +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 C881513C4BE for ; Tue, 10 Apr 2007 16:21:51 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 69E2D487F0; Tue, 10 Apr 2007 18:21:50 +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 2FFF048800; Tue, 10 Apr 2007 18:21:39 +0200 (CEST) Date: Tue, 10 Apr 2007 18:21:29 +0200 From: Pawel Jakub Dawidek To: "Rick C. Petty" Message-ID: <20070410162129.GI85578@garage.freebsd.pl> References: <20070409143818.GA86722@harmless.hu> <20070409152401.GG76673@garage.freebsd.pl> <20070409153203.GA88082@harmless.hu> <461A5EC6.8010000@freebsd.org> <20070409154407.GA88621@harmless.hu> <20070410111957.GA85578@garage.freebsd.pl> <461B75B2.40201@fer.hr> <20070410114115.GB85578@garage.freebsd.pl> <20070410161445.GA18858@keira.kiwi-computer.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W/D3X8sky0X3AmG5" Content-Disposition: inline In-Reply-To: <20070410161445.GA18858@keira.kiwi-computer.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@FreeBSD.org Subject: Re: volume management 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, 10 Apr 2007 16:21:52 -0000 --W/D3X8sky0X3AmG5 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 10, 2007 at 11:14:45AM -0500, Rick C. Petty wrote: > On Tue, Apr 10, 2007 at 01:41:15PM +0200, Pawel Jakub Dawidek wrote: > > On Tue, Apr 10, 2007 at 01:32:02PM +0200, Ivan Voras wrote: > > > Pawel Jakub Dawidek wrote: > > >=20 > > > >1. Panic if there is no physical storage. This way you protect > > > > consistency. You already printed a warning that gvirstor is runni= ng > > > > out of physical storage, so administrator has a chance to do the = job. > > >=20 > > > I really don't want to do that :( > >=20 > > If you have important data, this is really not bad idea. I, for one, > > prefer my kernel to panic, so I can see what exactly went wrong, add > > another disk and reboot instead of allowing kernel goes into wild by > > returning an error which won't be handled properly. >=20 > It's a terrible idea! What happens to all uncommitted soft updates and > other unwritten cached blocks? Lost forever, which can have bad effects = on > file systems and at the very least require everything to be fsck'd and GE= OM > mirrored or raid objects to be resync'd. What's wrong with ENOSPC? Isn't > that the whole point of that error? Let the admin know that something > failed, don't panic and prevent any further operation period. >=20 > I know I don't want my fileserver to panic just because I accidently try = to > add 100 GB instead of 10 GB or some other simple miscalculation. We have > enough panics in the kernel already for cases that should be handled bett= er > in userland. The choice you have currently is to panic and lost few last seconds of your data, but keep file system in a consistent state, or to return ENOSPC which nobody is going to handle and which may at the end corrupt your file system to a state that fsck won't be able to fix it. This is not about simple write operation to the disk. Those operations are delayed anyway, your userland process will see the write operation succeeded. This is about kernel and file system consistency. It will be great to just fix everything in the kernel to handle errors properly, but good luck with that. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --W/D3X8sky0X3AmG5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGG7mIForvXbEpPzQRAu1yAJ93sEuXV520JrXUG2Xxrj1ONhM4OwCdFkP+ l/zzmy2ChRxfbwWKdYYBEyo= =24t9 -----END PGP SIGNATURE----- --W/D3X8sky0X3AmG5-- From owner-freebsd-geom@FreeBSD.ORG Tue Apr 10 17:26:06 2007 Return-Path: X-Original-To: freebsd-geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C99F16A409 for ; Tue, 10 Apr 2007 17:26:06 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (keira.kiwi-computer.com [63.224.10.3]) by mx1.freebsd.org (Postfix) with SMTP id B908413C487 for ; Tue, 10 Apr 2007 17:26:05 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: (qmail 21608 invoked by uid 2001); 10 Apr 2007 17:26:04 -0000 Date: Tue, 10 Apr 2007 12:26:04 -0500 From: "Rick C. Petty" To: freebsd-geom@FreeBSD.org Message-ID: <20070410172604.GA21036@keira.kiwi-computer.com> References: <20070409152401.GG76673@garage.freebsd.pl> <20070409153203.GA88082@harmless.hu> <461A5EC6.8010000@freebsd.org> <20070409154407.GA88621@harmless.hu> <20070410111957.GA85578@garage.freebsd.pl> <461B75B2.40201@fer.hr> <20070410114115.GB85578@garage.freebsd.pl> <20070410161445.GA18858@keira.kiwi-computer.com> <20070410162129.GI85578@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070410162129.GI85578@garage.freebsd.pl> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: volume management X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2007 17:26:06 -0000 On Tue, Apr 10, 2007 at 06:21:29PM +0200, Pawel Jakub Dawidek wrote: > > The choice you have currently is to panic and lost few last seconds of > your data, but keep file system in a consistent state, or to return How can you guarantee the FS is consistent at that point? Are you looking through the list of blocks to be written? Granted, with soft updates this is less risky, because presumably the metadata blocks haven't been written until the data blocks are. > ENOSPC which nobody is going to handle and which may at the end corrupt > your file system to a state that fsck won't be able to fix it. Is a file system thread waiting on the block to be written, or because it's in a write cache is the caller lost forever? I thought the UFS soft updates code was blocking on the write, even though the userland caller had a successful return. If so, the FS should handle the error and avoid inconsistencies. I certainly see this type of behavior in gvinum when a disk is lost and a write to a slice cannot finish successfully. I'm very glad the box doesn't panic as often because I can sometimes go in and bring the drive back up. > This is not about simple write operation to the disk. Those operations > are delayed anyway, your userland process will see the write operation > succeeded. This is about kernel and file system consistency. I'm aware of that, but what's the call stack leading up to the GEOM failure? I was under the impression that UFS was blocked waiting for a write operation, which is all done in the kernel anyway. > It will be > great to just fix everything in the kernel to handle errors properly, > but good luck with that. That's a worthy goal and something we should be pursuing. After all, FreeBSD used to be noted for its stability. I wouldn't call panics a sign of stability.. You're better off invalidating all the geom consumers and leaving the rest of the system up so an admin can try to recover critical data, or so the remaining geom providers can continue to function. -- Rick C. Petty From owner-freebsd-geom@FreeBSD.ORG Tue Apr 10 17:42:35 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4EA4816A405 for ; Tue, 10 Apr 2007 17:42:35 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id 1B13E13C4C2 for ; Tue, 10 Apr 2007 17:42:34 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l3AHgT3d033706; Tue, 10 Apr 2007 12:42:29 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <461BCC85.2080900@freebsd.org> Date: Tue, 10 Apr 2007 12:42:29 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.10 (X11/20070320) MIME-Version: 1.0 To: rick-freebsd@kiwi-computer.com References: <20070409152401.GG76673@garage.freebsd.pl> <20070409153203.GA88082@harmless.hu> <461A5EC6.8010000@freebsd.org> <20070409154407.GA88621@harmless.hu> <20070410111957.GA85578@garage.freebsd.pl> <461B75B2.40201@fer.hr> <20070410114115.GB85578@garage.freebsd.pl> <20070410161445.GA18858@keira.kiwi-computer.com> <20070410162129.GI85578@garage.freebsd.pl> <20070410172604.GA21036@keira.kiwi-computer.com> In-Reply-To: <20070410172604.GA21036@keira.kiwi-computer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/3064/Tue Apr 10 11:25:23 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: freebsd-geom@freebsd.org Subject: Re: volume management 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, 10 Apr 2007 17:42:35 -0000 On 04/10/07 12:26, Rick C. Petty wrote: > On Tue, Apr 10, 2007 at 06:21:29PM +0200, Pawel Jakub Dawidek wrote: >> The choice you have currently is to panic and lost few last seconds of >> your data, but keep file system in a consistent state, or to return > > How can you guarantee the FS is consistent at that point? Are you looking > through the list of blocks to be written? Granted, with soft updates this > is less risky, because presumably the metadata blocks haven't been written > until the data blocks are. > >> ENOSPC which nobody is going to handle and which may at the end corrupt >> your file system to a state that fsck won't be able to fix it. > > Is a file system thread waiting on the block to be written, or because it's > in a write cache is the caller lost forever? I thought the UFS soft > updates code was blocking on the write, even though the userland caller had > a successful return. If so, the FS should handle the error and avoid > inconsistencies. > > I certainly see this type of behavior in gvinum when a disk is lost and a > write to a slice cannot finish successfully. I'm very glad the box doesn't > panic as often because I can sometimes go in and bring the drive back up. > >> This is not about simple write operation to the disk. Those operations >> are delayed anyway, your userland process will see the write operation >> succeeded. This is about kernel and file system consistency. > > I'm aware of that, but what's the call stack leading up to the GEOM > failure? I was under the impression that UFS was blocked waiting for a > write operation, which is all done in the kernel anyway. I think the issue is that UFS doesn't expect to see ENOSPC from the storage, since it believes it's on a provider that should be big enough. Is the right thing to teach UFS to recognize ENOSPC, and pass that on to the userland? >> It will be >> great to just fix everything in the kernel to handle errors properly, >> but good luck with that. > > That's a worthy goal and something we should be pursuing. After all, > FreeBSD used to be noted for its stability. I wouldn't call panics a sign > of stability.. You're better off invalidating all the geom consumers and > leaving the rest of the system up so an admin can try to recover critical > data, or so the remaining geom providers can continue to function. There's been talk in the past about making the mount read-only instead of a panic in some situations, but I know nothing more than that. Eric From owner-freebsd-geom@FreeBSD.ORG Tue Apr 10 17:45:26 2007 Return-Path: X-Original-To: freebsd-geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 867B516A405 for ; Tue, 10 Apr 2007 17:45:26 +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 06BB713C4BE for ; Tue, 10 Apr 2007 17:45:25 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id CDE0348800; Tue, 10 Apr 2007 19:45:23 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 0C8CB45B26; Tue, 10 Apr 2007 19:45:09 +0200 (CEST) Date: Tue, 10 Apr 2007 19:45:01 +0200 From: Pawel Jakub Dawidek To: "Rick C. Petty" Message-ID: <20070410174501.GA90135@garage.freebsd.pl> References: <20070409153203.GA88082@harmless.hu> <461A5EC6.8010000@freebsd.org> <20070409154407.GA88621@harmless.hu> <20070410111957.GA85578@garage.freebsd.pl> <461B75B2.40201@fer.hr> <20070410114115.GB85578@garage.freebsd.pl> <20070410161445.GA18858@keira.kiwi-computer.com> <20070410162129.GI85578@garage.freebsd.pl> <20070410172604.GA21036@keira.kiwi-computer.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline In-Reply-To: <20070410172604.GA21036@keira.kiwi-computer.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=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-geom@FreeBSD.org Subject: Re: volume management 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, 10 Apr 2007 17:45:26 -0000 --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 10, 2007 at 12:26:04PM -0500, Rick C. Petty wrote: > On Tue, Apr 10, 2007 at 06:21:29PM +0200, Pawel Jakub Dawidek wrote: > >=20 > > The choice you have currently is to panic and lost few last seconds of > > your data, but keep file system in a consistent state, or to return >=20 > How can you guarantee the FS is consistent at that point? [...] Because writing data order wasn't messed up. > > It will be > > great to just fix everything in the kernel to handle errors properly, > > but good luck with that. >=20 > That's a worthy goal and something we should be pursuing. After all, > FreeBSD used to be noted for its stability. I wouldn't call panics a sign > of stability.. You're better off invalidating all the geom consumers and > leaving the rest of the system up so an admin can try to recover critical > data, or so the remaining geom providers can continue to function. You don't understand. Do you think that adding 'return' in panic(9) will improve stability of your system? The point I'm trying to make here is that when some random write was lost, your file system is in undefined state and don't worry, it will panic your kernel at some point, but then you won't be able to tell why exactly. Your file system also can be corrupted because of this. UFS probably handle well situations when there is a problem writing data, but there are many places in the code (mostly for metadata) where return value is not checked. Error recovery is hard, even finding all those places, doesn't mean you will be able to do anything useful with those errors without reconstrucing the code. For example ZFS automatically panics when it can't write some important metadata - it doesn't even try to pass the error to userland, because it's simply not that easy. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --2fHTh5uZTiUOsy+g Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGG80dForvXbEpPzQRAgRMAKCtchJfr7iX4Xb5GTNLlxYG/7QtIQCfX5PN mJ4jNQHMW9+KRWFTBjq7Jp8= =hpUu -----END PGP SIGNATURE----- --2fHTh5uZTiUOsy+g-- From owner-freebsd-geom@FreeBSD.ORG Tue Apr 10 17:46:10 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 02A6616A403; Tue, 10 Apr 2007 17:46:10 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) by mx1.freebsd.org (Postfix) with ESMTP id 7B8F413C468; Tue, 10 Apr 2007 17:46:09 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from localhost (marvin-mail [192.168.0.2]) by marvin.harmless.hu (Postfix) with ESMTP id 847F27C0C4B; Tue, 10 Apr 2007 19:46:08 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.4.2 (20060627) (Debian) at harmless.hu Received: from marvin.harmless.hu ([192.168.0.2]) by localhost (marvin.harmless.hu [192.168.0.2]) (amavisd-new, port 10024) with ESMTP id cz8vX9BkQscK; Tue, 10 Apr 2007 19:46:08 +0200 (CEST) Received: from marvin.harmless.hu (localhost [127.0.0.1]) by marvin.harmless.hu (Postfix) with ESMTP id 2E1CE7C0C44; Tue, 10 Apr 2007 19:46:07 +0200 (CEST) Date: Tue, 10 Apr 2007 19:46:07 +0200 From: Gergely CZUCZY To: Eric Anderson Message-ID: <20070410174607.GA26432@harmless.hu> References: <461A5EC6.8010000@freebsd.org> <20070409154407.GA88621@harmless.hu> <20070410111957.GA85578@garage.freebsd.pl> <461B75B2.40201@fer.hr> <20070410114115.GB85578@garage.freebsd.pl> <20070410161445.GA18858@keira.kiwi-computer.com> <20070410162129.GI85578@garage.freebsd.pl> <20070410172604.GA21036@keira.kiwi-computer.com> <461BCC85.2080900@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline In-Reply-To: <461BCC85.2080900@freebsd.org> User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: freebsd-geom@freebsd.org Subject: Re: volume management 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, 10 Apr 2007 17:46:10 -0000 --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 10, 2007 at 12:42:29PM -0500, Eric Anderson wrote: > >>It will be > >>great to just fix everything in the kernel to handle errors properly, > >>but good luck with that. > >That's a worthy goal and something we should be pursuing. After all, > >FreeBSD used to be noted for its stability. I wouldn't call panics a si= gn > >of stability.. You're better off invalidating all the geom consumers and > >leaving the rest of the system up so an admin can try to recover critical > >data, or so the remaining geom providers can continue to function. >=20 > There's been talk in the past about making the mount read-only instead of= a panic in some=20 > situations, but I know nothing more than that. I quite like this idea, but what about updates? I don't know whether updates require additional space for UFS2 or not, but I can imagine the opportunity when updates can be done while there is no more space for allocating new blocks. Bye, Gergely Czuczy mailto: gergely.czuczy@harmless.hu --=20 Weenies test. Geniuses solve problems that arise. --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) owFNVM+LHEUYXZN4aVDIxYsg322RTE9mejabzchu3GSzyxJ/BDIi4kFqur+eLqe6 qq0fM+kFL55yEJSchBzMIeQmmJCD99wUxf/AQ0BPgjcvCr7q2VFvXVVfvfe+972u L186u3Hm/E/fPv3wwuf37r/wzbln0wt18F7P0lrYhdTpcDAYptn21ihLt9PRztZO Nrp0eTTczkdXiuzw1R8/um60Z+3TSdvwmDzf8RcbJaR+g/JKWMd+N/gy3UnWdQfS NcZJL40ek9RKav73bGKFdiXb9IbOTSH1bEyfBOO5SBsrtRdTxUnyrqZJ4B7tN5aG gx5lg8FlEp6G2XgrG2dXbr1N6eDSACc3rMxpXxdsndG0tEAaJ3u0t3fsaSmVoil3 y5ll3PeGPg7OUynvEC/Ytr6CAkgkXzHN2WpWsagSulBMbK2xjhprGraq7XVI0+Bp ZkxBKuRzcPgKl4Xvx8MJPjYdCVoa66sWdUIRsMiZmldcSyZXmaAKKKMmWBew2yfa Lz1bEkp1LIeW+drtAwqOiygItTqaRKWxJL0jB6ekkr7F1WPQAVBvesoBQI3QMo8q nNxNZjrimfJ/N3DlAxM2LQPWR1ZTlvBgIZQshI8iI0p0ZMamptxoF2oYHDuJYIrF IlbFCsuwE+jx27XOc02hQbuoJVHUcDbHl7dt7MJybuA65RbZgNQIBkbRI3SFOyvA GsmK8B05vF/ION0OB1KgL3AEK4POY8Jg/G42ANSkYstwf8oMRqHm67k2AhrF1GBw tZivldcmaA86UaRGqxbFUC8KNLObwLvOxIgQR7ciQKKDiJSuRzEFxzTXZhkH0022 NnAUUdCneThGsKVnUnIe96UjNCJWV5eoOJUUGljA7irgChNnGEGTZYW8wKrTU+gE GPBFUXT/FXLlGpFzF4j3Dm9n0UIo6eBBHd2StZjh1+u6NU2DSAaN+YMcBq2BYyHS BWrGgcTfF3mZIFebVU//ESEXJl9FRPOSpljNXT9JrrXcS5IjtjOGk9dPQn7SJpij 8maMOXbb/bzbfhMvRq3YuX4VkiRNo7XvY2ISWqDH9+kIC+QeGTdqwTEBeBNq17lK wkrH/eTu1bMvbsSnaf2unT9zdG7jwWe3fv7z9d/+fvrDzV9+/eOvLw7SZ09e2fj6 nZP23oNPH7782u+Pnr/1+Pn3i6++m/4D =E0Kj -----END PGP SIGNATURE----- --lrZ03NoBR/3+SXJZ-- From owner-freebsd-geom@FreeBSD.ORG Tue Apr 10 17:55:23 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 476C516A409 for ; Tue, 10 Apr 2007 17:55:23 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id 17F1013C4BC for ; Tue, 10 Apr 2007 17:55:23 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l3AHtMSE036108; Tue, 10 Apr 2007 12:55:22 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <461BCF8A.3030307@freebsd.org> Date: Tue, 10 Apr 2007 12:55:22 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.10 (X11/20070320) MIME-Version: 1.0 To: Gergely CZUCZY References: <461A5EC6.8010000@freebsd.org> <20070409154407.GA88621@harmless.hu> <20070410111957.GA85578@garage.freebsd.pl> <461B75B2.40201@fer.hr> <20070410114115.GB85578@garage.freebsd.pl> <20070410161445.GA18858@keira.kiwi-computer.com> <20070410162129.GI85578@garage.freebsd.pl> <20070410172604.GA21036@keira.kiwi-computer.com> <461BCC85.2080900@freebsd.org> <20070410174607.GA26432@harmless.hu> In-Reply-To: <20070410174607.GA26432@harmless.hu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/3064/Tue Apr 10 11:25:23 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: freebsd-geom@freebsd.org Subject: Re: volume management 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, 10 Apr 2007 17:55:23 -0000 On 04/10/07 12:46, Gergely CZUCZY wrote: > On Tue, Apr 10, 2007 at 12:42:29PM -0500, Eric Anderson wrote: >>>> It will be >>>> great to just fix everything in the kernel to handle errors properly, >>>> but good luck with that. >>> That's a worthy goal and something we should be pursuing. After all, >>> FreeBSD used to be noted for its stability. I wouldn't call panics a sign >>> of stability.. You're better off invalidating all the geom consumers and >>> leaving the rest of the system up so an admin can try to recover critical >>> data, or so the remaining geom providers can continue to function. >> There's been talk in the past about making the mount read-only instead of a panic in some >> situations, but I know nothing more than that. > I quite like this idea, but what about updates? I don't know > whether updates require additional space for UFS2 or not, but > I can imagine the opportunity when updates can be done while > there is no more space for allocating new blocks. I think the only time this might even be an option is under very minimal conditions. As Pawel said, if your FS is corrupt, you'll get hosed down the line. Personally, what I would want to prevent, is having a server go down due to one file system having an issue, when it is serving (or using) many more file systems. I currently have a box with 5 10Tb file systems on it, and when I mount a 6th file system (2Tb) which I *know* has metadata inconsistencies that fsck can't fix, I don't want it to take down all 50Tb of good solid storage. What I want is a blast to my logs, the erroneous file system to be evicted from further damage (mount read-only and marked as dirty) and trickle an i/o error to any processes trying to write to it. Even unmounting it would be ok, but that gets nasty with NFS servers and other things. Eric From owner-freebsd-geom@FreeBSD.ORG Tue Apr 10 18:14:27 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F159616A402 for ; Tue, 10 Apr 2007 18:14:27 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (keira.kiwi-computer.com [63.224.10.3]) by mx1.freebsd.org (Postfix) with SMTP id 9284013C4BF for ; Tue, 10 Apr 2007 18:14:27 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: (qmail 23006 invoked by uid 2001); 10 Apr 2007 18:14:26 -0000 Date: Tue, 10 Apr 2007 13:14:26 -0500 From: "Rick C. Petty" To: freebsd-geom@freebsd.org Message-ID: <20070410181426.GB21036@keira.kiwi-computer.com> References: <20070410111957.GA85578@garage.freebsd.pl> <461B75B2.40201@fer.hr> <20070410114115.GB85578@garage.freebsd.pl> <20070410161445.GA18858@keira.kiwi-computer.com> <20070410162129.GI85578@garage.freebsd.pl> <20070410172604.GA21036@keira.kiwi-computer.com> <461BCC85.2080900@freebsd.org> <20070410174607.GA26432@harmless.hu> <461BCF8A.3030307@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <461BCF8A.3030307@freebsd.org> User-Agent: Mutt/1.4.2.1i Subject: Re: volume management X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2007 18:14:28 -0000 On Tue, Apr 10, 2007 at 12:55:22PM -0500, Eric Anderson wrote: > > Personally, what I would want to prevent, is having a server go down due > to one file system having an issue, when it is serving (or using) many > more file systems. Exactly my point. The whole machine isn't hosed, just N file systems who use that GEOM provider. > What I want is a blast to my logs, the > erroneous file system to be evicted from further damage (mount read-only > and marked as dirty) and trickle an i/o error to any processes trying to > write to it. Even unmounting it would be ok, but that gets nasty with > NFS servers and other things. This is why I suggested that you propagate down to the GEOM consumers of the bad provider, either disallowing writes (which I don't think is a GEOM option) or removing the device completely... the file systems should be unmounted, etc. I pointed out that this seems already the case I've seen in gvinum when a disk is dropped... gvinum noticed the device failure and marked all dependencies as stale, and the only problem I had was a mounted stripe. 90% of the time I was able to kill all user processes which were reading or writing to the bad stripe, bring the disk back up, and force remounting the filesystem. Both UFS and GEOM code are buggy here-- sometimes I would get a panic and have to fsck (and resync) terabytes of disks, but often if I wait long enough after killing the user process everything else times out and I'm able to remount the filesystem and continue. I was never stating that the UFS subsystem is robust enough to handle all the failures, but that the GEOM layer should do what it can to keep the box up and we should train UFS and other filesystems how to handle these failures better. But a panic is just not a pretty option. One GEOM provider should not be arrogant enough to say that the box is no longer usable at all. That's like engineering an automobile which locks up the steering wheel and locks the doors and windows after noticing that one tire just went flat-- preventing the driver from attempting to safely pull over and preventing any passengers from exiting the vehicle. -- Rick C. Petty From owner-freebsd-geom@FreeBSD.ORG Tue Apr 10 18:28:21 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 48C8C16A40A for ; Tue, 10 Apr 2007 18:28:21 +0000 (UTC) (envelope-from tomas@zvala.cz) Received: from neptune.request.cz (fox.murder.cz [62.24.64.129]) by mx1.freebsd.org (Postfix) with ESMTP id 08FAA13C4D5 for ; Tue, 10 Apr 2007 18:28:20 +0000 (UTC) (envelope-from tomas@zvala.cz) Received: from [192.168.1.2] (r6l254.net.upc.cz [89.176.11.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fox@murder.cz) by neptune.request.cz (Postfix) with ESMTP id E36504800081 for ; Tue, 10 Apr 2007 20:00:08 +0200 (CEST) Message-ID: <461BD0DC.5070802@zvala.cz> Date: Tue, 10 Apr 2007 20:01:00 +0200 From: Tomas Zvala User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: freebsd-geom@freebsd.org References: <461A5EC6.8010000@freebsd.org> <20070409154407.GA88621@harmless.hu> <20070410111957.GA85578@garage.freebsd.pl> <461B75B2.40201@fer.hr> <20070410114115.GB85578@garage.freebsd.pl> <20070410161445.GA18858@keira.kiwi-computer.com> <20070410162129.GI85578@garage.freebsd.pl> <20070410172604.GA21036@keira.kiwi-computer.com> <461BCC85.2080900@freebsd.org> <20070410174607.GA26432@harmless.hu> <461BCF8A.3030307@freebsd.org> In-Reply-To: <461BCF8A.3030307@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: volume management 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, 10 Apr 2007 18:28:21 -0000 Eric Anderson wrote: > > I think the only time this might even be an option is under very > minimal conditions. As Pawel said, if your FS is corrupt, you'll get > hosed down the line. > > Personally, what I would want to prevent, is having a server go down > due to one file system having an issue, when it is serving (or using) > many more file systems. I currently have a box with 5 10Tb file > systems on it, and when I mount a 6th file system (2Tb) which I *know* > has metadata inconsistencies that fsck can't fix, I don't want it to > take down all 50Tb of good solid storage. What I want is a blast to > my logs, the erroneous file system to be evicted from further damage > (mount read-only and marked as dirty) and trickle an i/o error to any > processes trying to write to it. Even unmounting it would be ok, but > that gets nasty with NFS servers and other things. > > > Eric > This might as well be a dumb question... But ... Why don't we let the root choose, what is supposed to happen? That makes most sense to me and even though i'm no fbsd hacker, it seems to me as not a big deal to implement. Tomas From owner-freebsd-geom@FreeBSD.ORG Thu Apr 12 14:39:49 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 078BD16A404 for ; Thu, 12 Apr 2007 14:39:49 +0000 (UTC) (envelope-from dmehler26@woh.rr.com) Received: from ms-smtp-05.ohiordc.rr.com (ms-smtp-05.ohiordc.rr.com [65.24.5.139]) by mx1.freebsd.org (Postfix) with ESMTP id 9D5DC13C46A for ; Thu, 12 Apr 2007 14:39:48 +0000 (UTC) (envelope-from dmehler26@woh.rr.com) Received: from satellite (cpe-71-64-129-15.woh.res.rr.com [71.64.129.15]) by ms-smtp-05.ohiordc.rr.com (8.13.6/8.13.6) with SMTP id l3CE0GV0015788 for ; Thu, 12 Apr 2007 10:00:19 -0400 (EDT) Message-ID: <000901c77d0a$f7ae51d0$0200a8c0@satellite> From: "Dave" To: Date: Thu, 12 Apr 2007 10:00:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Virus-Scanned: Symantec AntiVirus Scan Engine Subject: issues with geom and adding disks X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2007 14:39:49 -0000 Hello, I'm following the handbook section 18.3.2.1 to add a disk to a FreeBSD 6.2 system. I've got the disk plugged in and it shows up as /dev/ad6 so i did: dd if=/dev/zero of=/dev/ad6 bs=1k count=1 That worked fine. My problem came with fdisk. I used: fdisk -BI ad6 and i got the message: Invalid partition table geom not found. If i do: fdisk ad6 i get a summary of the current disk partitions on ad6, all empty as this is a new disk. Thanks. Dave. From owner-freebsd-geom@FreeBSD.ORG Thu Apr 12 20:00:53 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6DA4F16A415 for ; Thu, 12 Apr 2007 20:00:53 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 2E4C113C48A for ; Thu, 12 Apr 2007 20:00:53 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 345F02094; Thu, 12 Apr 2007 22:00:49 +0200 (CEST) X-Spam-Tests: AWL,MAILTO_TO_SPAM_ADDR X-Spam-Learn: disabled X-Spam-Score: 0.2/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 171332091; Thu, 12 Apr 2007 22:00:49 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id D7AD053AC; Thu, 12 Apr 2007 22:00:48 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Dave References: <000901c77d0a$f7ae51d0$0200a8c0@satellite> Date: Thu, 12 Apr 2007 22:00:48 +0200 In-Reply-To: <000901c77d0a$f7ae51d0$0200a8c0@satellite> (dmehler26@woh.rr.com's message of "Thu, 12 Apr 2007 10:00:43 -0400") Message-ID: <86wt0he51r.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-geom@freebsd.org Subject: Re: issues with geom and adding 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: Thu, 12 Apr 2007 20:00:53 -0000 "Dave" writes: > That worked fine. My problem came with fdisk. I used: > > fdisk -BI ad6 > > and i got the message: > > Invalid partition table > geom not found. It says "invalid partition table" because there is no pre-existing partition table on the disk. This will not show up again if you run 'fdisk -I ad6' a second time. I don't know what "Geom not found" comes from (a bug in either fdisk or libgeom?) but it seems to be harmless as well; fdisk ignores the error and goes on to write the updated MBR to the disk. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-geom@FreeBSD.ORG Thu Apr 12 22:35:11 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4585D16A400 for ; Thu, 12 Apr 2007 22:35:11 +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 C5FA113C44C for ; Thu, 12 Apr 2007 22:35:10 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Hc7sb-0004g6-BK for freebsd-geom@freebsd.org; Fri, 13 Apr 2007 00:35:01 +0200 Received: from 83-131-171-94.adsl.net.t-com.hr ([83.131.171.94]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Apr 2007 00:35:01 +0200 Received: from ivoras by 83-131-171-94.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Apr 2007 00:35:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Fri, 13 Apr 2007 00:34:31 +0200 Lines: 38 Message-ID: References: <461A5EC6.8010000@freebsd.org> <20070409154407.GA88621@harmless.hu> <20070410111957.GA85578@garage.freebsd.pl> <461B75B2.40201@fer.hr> <20070410114115.GB85578@garage.freebsd.pl> <20070410161445.GA18858@keira.kiwi-computer.com> <20070410162129.GI85578@garage.freebsd.pl> <20070410172604.GA21036@keira.kiwi-computer.com> <461BCC85.2080900@freebsd.org> <20070410174607.GA26432@harmless.hu> <461BCF8A.3030307@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE1BD8BAF8C4A7C566686A774" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 83-131-171-94.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) In-Reply-To: <461BCF8A.3030307@freebsd.org> X-Enigmail-Version: 0.94.3.0 Sender: news Subject: Re: volume management 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, 12 Apr 2007 22:35:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE1BD8BAF8C4A7C566686A774 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Eric Anderson wrote: > Personally, what I would want to prevent, is having a server go down du= e > to one file system having an issue, when it is serving (or using) many > more file systems. I currently have a box with 5 10Tb file systems on > it, and when I mount a 6th file system (2Tb) which I *know* has metadat= a > inconsistencies that fsck can't fix, I don't want it to take down all > 50Tb of good solid storage. =20 This is slightly off-topic, but this is one of the reasons full virtualisation is used. If your kernel panics inside a VM, it's expendable :) --------------enigE1BD8BAF8C4A7C566686A774 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.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGHrP9ldnAQVacBcgRAp4JAKDGLuq0kEKq0TDTMK309W2cB3ypAQCeK8uF M8mhEa22p07xuc7mTOWVvTY= =DkQ5 -----END PGP SIGNATURE----- --------------enigE1BD8BAF8C4A7C566686A774-- From owner-freebsd-geom@FreeBSD.ORG Thu Apr 12 22:41:21 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0395D16A402 for ; Thu, 12 Apr 2007 22:41:21 +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 AE0DD13C45B for ; Thu, 12 Apr 2007 22:41:20 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Hc7yc-0005bl-AO for freebsd-geom@freebsd.org; Fri, 13 Apr 2007 00:41:14 +0200 Received: from 83-131-171-94.adsl.net.t-com.hr ([83.131.171.94]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Apr 2007 00:41:14 +0200 Received: from ivoras by 83-131-171-94.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Apr 2007 00:41:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Fri, 13 Apr 2007 00:40:52 +0200 Lines: 32 Message-ID: References: <20070409152401.GG76673@garage.freebsd.pl> <20070409153203.GA88082@harmless.hu> <461A5EC6.8010000@freebsd.org> <20070409154407.GA88621@harmless.hu> <20070410111957.GA85578@garage.freebsd.pl> <461B75B2.40201@fer.hr> <20070410114115.GB85578@garage.freebsd.pl> <20070410161445.GA18858@keira.kiwi-computer.com> <20070410162129.GI85578@garage.freebsd.pl> <20070410172604.GA21036@keira.kiwi-computer.com> <461BCC85.2080900@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig717EBA8E6710E7A1A144E517" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 83-131-171-94.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) In-Reply-To: <461BCC85.2080900@freebsd.org> X-Enigmail-Version: 0.94.3.0 Sender: news Subject: Re: volume management 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, 12 Apr 2007 22:41:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig717EBA8E6710E7A1A144E517 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Eric Anderson wrote: > I think the issue is that UFS doesn't expect to see ENOSPC from the > storage, since it believes it's on a provider that should be big enough= =2E > Is the right thing to teach UFS to recognize ENOSPC, and pass that on > to the userland? It's not just ENOSPC. Any error codes GEOM returns in code sections I've hit on (mostly softdep) will panic or confuse the kernel beyond repair. --------------enig717EBA8E6710E7A1A144E517 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.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGHrV0ldnAQVacBcgRAha1AKDSO9WYpCNOWxceqmcc6myUEW3YwQCgiRmI 3iVB7VovlKZnaa0sWimz3KY= =VUyc -----END PGP SIGNATURE----- --------------enig717EBA8E6710E7A1A144E517-- From owner-freebsd-geom@FreeBSD.ORG Thu Apr 12 23:17:38 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F95E16A403 for ; Thu, 12 Apr 2007 23:17:38 +0000 (UTC) (envelope-from david.cecil@nokia.com) Received: from mgw-ext13.nokia.com (smtp.nokia.com [131.228.20.172]) by mx1.freebsd.org (Postfix) with ESMTP id A1FC313C45B for ; Thu, 12 Apr 2007 23:17:37 +0000 (UTC) (envelope-from david.cecil@nokia.com) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3CMaQvH027597; Fri, 13 Apr 2007 01:36:27 +0300 Received: from siebh102.NOE.Nokia.com ([172.30.195.29]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 01:36:21 +0300 Received: from syebe101.NOE.Nokia.com ([172.30.128.65]) by siebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 06:36:18 +0800 Received: from [172.30.67.198] ([172.30.67.198]) by syebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 08:36:16 +1000 Message-ID: <461EB45F.8070001@nokia.com> Date: Fri, 13 Apr 2007 08:36:15 +1000 From: David Cecil User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: =?ISO-8859-1?Q?ext_Dag-Erling_Sm=F8rgrav?= References: <000901c77d0a$f7ae51d0$0200a8c0@satellite> <86wt0he51r.fsf@dwp.des.no> In-Reply-To: <86wt0he51r.fsf@dwp.des.no> X-OriginalArrivalTime: 12 Apr 2007 22:36:16.0974 (UTC) FILETIME=[FBDD8EE0:01C77D52] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070413013627-609B9BB0-0679B60F/0-0/0-1 X-Nokia-AV: Clean Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Dave , freebsd-geom@freebsd.org Subject: Re: issues with geom and adding 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: Thu, 12 Apr 2007 23:17:38 -0000 ext Dag-Erling Smørgrav wrote: > "Dave" writes: > >> That worked fine. My problem came with fdisk. I used: >> >> fdisk -BI ad6 >> >> and i got the message: >> >> Invalid partition table >> geom not found. >> > > It says "invalid partition table" because there is no pre-existing > partition table on the disk. This will not show up again if you run > 'fdisk -I ad6' a second time. > > I don't know what "Geom not found" comes from (a bug in either fdisk > or libgeom?) but it seems to be harmless as well; fdisk ignores the > error and goes on to write the updated MBR to the disk. > I tracked this down at one point and yes, it is harmless. If I recall correctly, it's due to there being no partition table. My memory for such things isn't the best though... Regards, Dave From owner-freebsd-geom@FreeBSD.ORG Fri Apr 13 12:58:19 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8B90E16A404 for ; Fri, 13 Apr 2007 12:58:19 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id 5A8A313C43E for ; Fri, 13 Apr 2007 12:58:19 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l3DCw85g055902; Fri, 13 Apr 2007 07:58:09 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <461F7E60.7090700@freebsd.org> Date: Fri, 13 Apr 2007 07:58:08 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.10 (X11/20070320) MIME-Version: 1.0 To: Ivan Voras References: <461A5EC6.8010000@freebsd.org> <20070409154407.GA88621@harmless.hu> <20070410111957.GA85578@garage.freebsd.pl> <461B75B2.40201@fer.hr> <20070410114115.GB85578@garage.freebsd.pl> <20070410161445.GA18858@keira.kiwi-computer.com> <20070410162129.GI85578@garage.freebsd.pl> <20070410172604.GA21036@keira.kiwi-computer.com> <461BCC85.2080900@freebsd.org> <20070410174607.GA26432@harmless.hu> <461BCF8A.3030307@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/3089/Fri Apr 13 05:08:40 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: freebsd-geom@freebsd.org Subject: Re: volume management 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, 13 Apr 2007 12:58:19 -0000 On 04/12/07 17:34, Ivan Voras wrote: > Eric Anderson wrote: > >> Personally, what I would want to prevent, is having a server go down due >> to one file system having an issue, when it is serving (or using) many >> more file systems. I currently have a box with 5 10Tb file systems on >> it, and when I mount a 6th file system (2Tb) which I *know* has metadata >> inconsistencies that fsck can't fix, I don't want it to take down all >> 50Tb of good solid storage. > > This is slightly off-topic, but this is one of the reasons full > virtualisation is used. If your kernel panics inside a VM, it's > expendable :) I'm not sure that makes a lot of sense. Honestly, it's not efficient to have a single virtual system for each mount point/file system, because of the overhead. You lose a lot doing that, and only gain the protection of a trapped panic inside a virtualized host. At least one major commercial file system vendor that I have a lot of direct experience with ejects the filesystem from the system if it incurs a serious issue, and returns i/o errors. Truthfully, it's *FAR* better than having the kernel panic and taking out the whole system. This conversation is really a -fs@ discussion, maybe we should move it there? Eric From owner-freebsd-geom@FreeBSD.ORG Sat Apr 14 12:18:56 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 57B7616A408; Sat, 14 Apr 2007 12:18:56 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [83.98.131.211]) by mx1.freebsd.org (Postfix) with ESMTP id 2075313C44B; Sat, 14 Apr 2007 12:18:55 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 7407F1CC42; Sat, 14 Apr 2007 13:59:59 +0200 (CEST) Date: Sat, 14 Apr 2007 13:59:59 +0200 From: Ed Schouten To: FreeBSD GEOM Message-ID: <20070414115959.GN81821@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nVYOjVWOcH+Ezkzp" Content-Disposition: inline User-Agent: Mutt/1.5.15 (2007-04-06) Cc: Rink Springer , Laurens Timmermans Subject: New GEOM module: geom_xboxhd 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, 14 Apr 2007 12:18:56 -0000 --nVYOjVWOcH+Ezkzp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, One of the problems of the current FreeBSD/xbox port is that it's not possible to install FreeBSD, while leaving the existing software alone. The Microsoft Xbox uses a custom disk layout which doesn't have a partition table format which specifies the geometries. All partitions are hardcoded. The last partition on the Xbox always has a variable size, because not all harddisks have the same size. The partition will never be bigger than 4895MB, so on Xboxes with a bigger harddisk, the Xbox software won't touch everything after 7645MB, which gives us space to install FreeBSD ;-) Linux has an evil hack to work around this; they have modified the x86 partition table code to start at 7645MB and create some device nodes (hda51 to hda55) which represent the partitions from the Xbox itself. I just wrote a GEOM module that just generates ad0s1 to ad0s5 and when the disk is big enough an ad0s6. My Xbox isn't capable anymore to deal with original Xbox harddisks anymore, so I tested it on my desktop with a snapshot of an Xbox harddisk from a friend of mine (thanks Laurens!). I've placed the code in a Git repository, which can be viewed online: http://g-rave.nl/gitweb?p=3Dgeom_xboxhd;a=3Dtree Yours, --=20 Ed Schouten WWW: http://g-rave.nl/ --nVYOjVWOcH+Ezkzp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGIMI/52SDGA2eCwURAjceAJ9wggcqR6MTjHIjlcq/N8dWX8DNIwCZAY9q C3UOwH3VKHADzoJDnn4cMro= =q5OB -----END PGP SIGNATURE----- --nVYOjVWOcH+Ezkzp-- From owner-freebsd-geom@FreeBSD.ORG Sat Apr 14 16:33:56 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D8FD316A401; Sat, 14 Apr 2007 16:33:56 +0000 (UTC) (envelope-from rink@thunderstone.rink.nu) Received: from mx1.rink.nu (thunderstone.rink.nu [80.112.228.34]) by mx1.freebsd.org (Postfix) with ESMTP id 9930213C45D; Sat, 14 Apr 2007 16:33:56 +0000 (UTC) (envelope-from rink@thunderstone.rink.nu) Received: from localhost (localhost [127.0.0.1]) by mx1.rink.nu (Postfix) with ESMTP id 3C0C2D4C61; Sat, 14 Apr 2007 18:06:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx1.rink.nu ([127.0.0.1]) by localhost (thunderstone.rink.nu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ns0SdPW3davc; Sat, 14 Apr 2007 18:06:30 +0200 (CEST) Received: from thunderstone.rink.nu (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.rink.nu (Postfix) with ESMTP id EC05CD4C60; Sat, 14 Apr 2007 18:06:29 +0200 (CEST) Received: (from rink@localhost) by thunderstone.rink.nu (8.13.8/8.13.8/Submit) id l3EG6TsY084820; Sat, 14 Apr 2007 18:06:29 +0200 (CEST) (envelope-from rink) Date: Sat, 14 Apr 2007 18:06:29 +0200 From: Rink Springer To: Ed Schouten Message-ID: <20070414160629.GA82214@rink.nu> References: <20070414115959.GN81821@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20070414115959.GN81821@hoeg.nl> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Rink Springer , Laurens Timmermans , FreeBSD GEOM Subject: Re: New GEOM module: geom_xboxhd 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, 14 Apr 2007 16:33:56 -0000 Hi Ed, On Sat, Apr 14, 2007 at 01:59:59PM +0200, Ed Schouten wrote: > I've placed the code in a Git repository, which can be viewed online: >=20 > http://g-rave.nl/gitweb?p=3Dgeom_xboxhd;a=3Dtree Some comments: (1) g_xboxhd_checkmagic(): You look at uint32_t* buf, which you have just g_free()'d; this seems wrong. I know this is debugging code, but you could just get rid of these lines all the same ;-) (2) I consider the for-loop in line 125 a bit kludgy - why not add all 'standard' partitions (of which you know they are always there) in this loop, and if the disk was larger, add a final paritition containing the rest? This makes the code prettier to read, in my opinion. (3) This may be personal preference, but I consider a check of 4 bytes on address 0x600 a bit weak - usually, the first 63 sectors or so after the boot sector are skipped during partitioning (most general boot managers reside there), so there may be no telling what's in there. However, there doesn't seem to be a better way to identify Xbox harddisks, which makes me wonder whether we should keep this in the XBOX kernel config file only, possibly commented out in LINT. Anyway, apart from this, it looks functional and something the xbox port could very well use. I'd like to get this in the tree, so people with more geom-fu are very welcome to take a look! Have you tried what sysinstall(8) does when it sees such a layout? It'd be a shame if it nuked the partition table... :-) Regards, --=20 Rink P.W. Springer - http://rink.nu "It is such a quiet thing, to fall. But yet a far more terrible thing, to admit it." - Darth Traya