From owner-freebsd-geom@FreeBSD.ORG Sun Aug 12 02:10:54 2007 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB66316A417 for ; Sun, 12 Aug 2007 02:10:54 +0000 (UTC) (envelope-from hg@queue.to) Received: from pickle.queue.to (pickle.queue.to [71.180.69.18]) by mx1.freebsd.org (Postfix) with ESMTP id 3E47413C442 for ; Sun, 12 Aug 2007 02:10:54 +0000 (UTC) (envelope-from hg@queue.to) Received: (qmail 83316 invoked from network); 11 Aug 2007 21:44:12 -0400 Received: from cally.queue.to (172.16.0.6) by pickle.queue.to with ESMTP; 11 Aug 2007 21:44:12 -0400 Message-ID: <46BE65EC.1050906@queue.to> Date: Sat, 11 Aug 2007 21:44:12 -0400 From: Howard Goldstein User-Agent: Thunderbird 2.0.0.6 (X11/20070802) MIME-Version: 1.0 To: freebsd-geom@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: graid5 or gvinums - bootable? 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, 12 Aug 2007 02:10:54 -0000 Apologies in advance for the dumb question. I request a reality check here as it takes a few hours (on graid5 at least) on my hardware for the provider to sync and this is on a production box I can't take down for too long. Q: Should a graid5 or gvinum provider be expected to be bootable, assuming the prover's partition table has an active bootable partition containing a properly bsdlabeled 'a' slice with the /boot subdirectories in it (i.e., all of the stuff you normally need in an ordinary, non-geom system to have a bootable slice)? Teh googling is somewhat helpful indicating that the boot loader can now deal with the GEOM'd gvinum as the boot device, and of course it works with gmirror but that's not really surprising since that provider wouldn't doesn't have its /boot slice striped into ribbons across multiple consumers like graid5 and gvinum in raid-5. From owner-freebsd-geom@FreeBSD.ORG Sun Aug 12 04:30:54 2007 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0394416A420 for ; Sun, 12 Aug 2007 04:30:54 +0000 (UTC) (envelope-from arne_woerner@yahoo.com) Received: from web30303.mail.mud.yahoo.com (web30303.mail.mud.yahoo.com [209.191.69.65]) by mx1.freebsd.org (Postfix) with SMTP id AC73B13C494 for ; Sun, 12 Aug 2007 04:30:53 +0000 (UTC) (envelope-from arne_woerner@yahoo.com) Received: (qmail 18663 invoked by uid 60001); 12 Aug 2007 04:30:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=MEaAvsjPdHWlwyAI6tNUvsQtnxZwikWwtc0dTRkpc8al6cn7OwFFZA/vUc0M91HSTJDrW1a6YFz65sceHuNAGL6MubkzjAeijB6kY98MNDS/sV7c6QGtjvfPTrg95SdQUNOZ/Vj5YbOmTYbrXkV8nJgHEbNWZdjy3sQ9dyApjDI=; X-YMail-OSG: JGB5hOIVM1kiFc9PCCoBkAhiIA6_w0zeIWJ8VPfJZSx62.RXrsxIgpEDNlJE6RvpQA-- Received: from [84.141.110.96] by web30303.mail.mud.yahoo.com via HTTP; Sat, 11 Aug 2007 21:30:52 PDT Date: Sat, 11 Aug 2007 21:30:52 -0700 (PDT) From: Arne "Wörner" To: Howard Goldstein , freebsd-geom@freebsd.org In-Reply-To: <46BE65EC.1050906@queue.to> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <737268.12931.qm@web30303.mail.mud.yahoo.com> Cc: Subject: Re: graid5 or gvinums - bootable? 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, 12 Aug 2007 04:30:54 -0000 --- Howard Goldstein wrote: > Q: Should a graid5 or gvinum provider be expected to be bootable, > assuming the prover's partition table has an active bootable partition > containing a properly bsdlabeled 'a' slice with the /boot subdirectories > in it (i.e., all of the stuff you normally need in an ordinary, non-geom > system to have a bootable slice)? > Wont work with graid5... I use a RAID1 (graid5 in 2-disk-mode) for /boot... :-) I dont know, if gvinum can do that... But I doubt it... -Arne ____________________________________________________________________________________ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC From owner-freebsd-geom@FreeBSD.ORG Sun Aug 12 04:31:30 2007 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4D4116A417 for ; Sun, 12 Aug 2007 04:31:30 +0000 (UTC) (envelope-from cyberleo@cyberleo.net) Received: from pizzabox.cyberleo.net (alpha.cyberleo.net [198.145.45.10]) by mx1.freebsd.org (Postfix) with ESMTP id 71AA613C468 for ; Sun, 12 Aug 2007 04:31:30 +0000 (UTC) (envelope-from cyberleo@cyberleo.net) Received: (qmail 38847 invoked from network); 12 Aug 2007 04:04:48 -0000 Received: from adsl-75-3-83-251.dsl.chcgil.sbcglobal.net (HELO ?172.16.44.14?) (cyberleo@cyberleo.net@75.3.83.251) by alpha.cyberleo.net with ESMTPA; 12 Aug 2007 04:04:48 -0000 Message-ID: <46BE79AE.2070007@cyberleo.net> Date: Sat, 11 Aug 2007 22:08:07 -0500 From: CyberLeo Kitsana User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Howard Goldstein References: <46BE65EC.1050906@queue.to> In-Reply-To: <46BE65EC.1050906@queue.to> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Geom Subject: Re: graid5 or gvinums - bootable? 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, 12 Aug 2007 04:31:31 -0000 Howard Goldstein wrote: > Q: Should a graid5 or gvinum provider be expected to be bootable, > assuming the prover's partition table has an active bootable partition > containing a properly bsdlabeled 'a' slice with the /boot subdirectories > in it (i.e., all of the stuff you normally need in an ordinary, non-geom > system to have a bootable slice)? > > Teh googling is somewhat helpful indicating that the boot loader can now > deal with the GEOM'd gvinum as the boot device, and of course it works > with gmirror but that's not really surprising since that provider > wouldn't doesn't have its /boot slice striped into ribbons across > multiple consumers like graid5 and gvinum in raid-5. I haven't tried with just /boot, but I have a machine with a 1.5GB mirror across four disks for the root filesystem, with a graid5 across the remaining space for the other filesystems. That works just fine. As far as I know, however, no boot loader can understand software-striped or software-raid5ed filesystems, given that it would essentially need to implement the relevant geom providers itself. -- Fuzzy love, -CyberLeo Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net Furry Peace! - http://wwww.fur.com/peace/ From owner-freebsd-geom@FreeBSD.ORG Sun Aug 12 15:24:40 2007 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3807C16A417 for ; Sun, 12 Aug 2007 15:24:40 +0000 (UTC) (envelope-from cyberleo@cyberleo.net) Received: from pizzabox.cyberleo.net (alpha.cyberleo.net [198.145.45.10]) by mx1.freebsd.org (Postfix) with ESMTP id 0054213C459 for ; Sun, 12 Aug 2007 15:24:39 +0000 (UTC) (envelope-from cyberleo@cyberleo.net) Received: (qmail 52790 invoked from network); 12 Aug 2007 15:24:39 -0000 Received: from adsl-75-3-83-251.dsl.chcgil.sbcglobal.net (HELO ?172.16.44.14?) (cyberleo@cyberleo.net@75.3.83.251) by alpha.cyberleo.net with ESMTPA; 12 Aug 2007 15:24:39 -0000 Message-ID: <46BF256B.7040808@cyberleo.net> Date: Sun, 12 Aug 2007 10:20:52 -0500 From: CyberLeo Kitsana User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Howard Goldstein References: <737268.12931.qm@web30303.mail.mud.yahoo.com> <46BF12DC.4020107@queue.to> In-Reply-To: <46BF12DC.4020107@queue.to> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?=22Arne_=5C=22W=F6rner=5C=22=22?= , FreeBSD Geom Subject: Re: glabeled units as consumers? gstriping swap and /tmp? (was Re: graid5 or gvinums - bootable?) 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, 12 Aug 2007 15:24:40 -0000 Howard Goldstein wrote: > Arne, CyberLeo, sounds great, gmirroring the root partition seems a far > more optimal approach than mine anyway. Thanks for setting me straight. > > A couple of other dumb questions if I may: > > - Is it possible (does it even make sense?) to glabel the consumers and > specifying the appropriate bits of the resulting label as gmirror and > graid5 consumers? Not quite sure what you're asking. Labeling the disks, then using the labels in the mirror or raid, or applying a label to the resultant mirror or raid? In the former case, I don't think that's necessary, given that the geom taste functions will find the correct consumers regardless. As for the latter, the geom providers are set up with unique, canonical device names, so glabel may be unnecessary. > - How are you all handling the swap slice? (gstriping?) Since my disks are not hot-swappable, the machines will need to reboot to notice replacements anyways. A single swap slice in the same spot on each disk works fine for me. > - Is /tmp a good candidate for gstriping as well? Assuming everything > I've put in there is ephemeral anway. In theory. I've never bothered, because I don't use /tmp for anything more than what the OS itself uses. It's not worth the added complexity for my applications. -- Fuzzy love, -CyberLeo Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net Furry Peace! - http://wwww.fur.com/peace/ From owner-freebsd-geom@FreeBSD.ORG Sun Aug 12 16:43:16 2007 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C968E16A418 for ; Sun, 12 Aug 2007 16:43:16 +0000 (UTC) (envelope-from arne_woerner@yahoo.com) Received: from web30313.mail.mud.yahoo.com (web30313.mail.mud.yahoo.com [209.191.69.75]) by mx1.freebsd.org (Postfix) with SMTP id 798AC13C465 for ; Sun, 12 Aug 2007 16:43:16 +0000 (UTC) (envelope-from arne_woerner@yahoo.com) Received: (qmail 14038 invoked by uid 60001); 12 Aug 2007 16:43:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=P8XyFKMW74E1q/UnIyx3gcW4CDMZuQDMfOL0vf7iCYRLoewGFF+5wrx6OYnmmm91MbCbHBIZBNnpbptatxyUBqj99du+IJF52qX133fOTIpsuvTgIgUZWiXo2TDLdToa5I/loo+ilqtoGVDTfa45gBiWw7CKeqK0DX98JhGmvzQ=; X-YMail-OSG: MQjnrIEVM1lqtSBD62l1Yt54NoeJsPlZlpeaAZTa Received: from [84.141.110.96] by web30313.mail.mud.yahoo.com via HTTP; Sun, 12 Aug 2007 09:43:13 PDT Date: Sun, 12 Aug 2007 09:43:13 -0700 (PDT) From: Arne "Wörner" To: freebsd-geom@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <830352.13839.qm@web30313.mail.mud.yahoo.com> Subject: Re: glabeled units as consumers? gstriping swap and /tmp? (was Re: graid5 or gvinums - bootable?) 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, 12 Aug 2007 16:43:16 -0000 --- Howard Goldstein wrote: > - Is it possible (does it even make sense?) to glabel the consumers and > specifying the appropriate bits of the resulting label as gmirror and > graid5 consumers? > Since graid5 already put meta data into the last sector of each of its consumers, a glabel is not necessary... I think glabel makes more sense, when u use it in /etc/fstab... > - How are you all handling the swap slice? (gstriping?) > For fail safety reasons: graid5 in 2-disk-mode... :-)) > - Is /tmp a good candidate for gstriping as well? Assuming everything > I've put in there is ephemeral anway. > RAID1, too... At least the box wont crash then, when a disk starts burning... -Arne ____________________________________________________________________________________ Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting From owner-freebsd-geom@FreeBSD.ORG Mon Aug 13 01:06:47 2007 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74BA316A417 for ; Mon, 13 Aug 2007 01:06:47 +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 F11FA13C45D for ; Mon, 13 Aug 2007 01:06:46 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IKOOE-0002Op-NL for freebsd-geom@freebsd.org; Mon, 13 Aug 2007 03:06:38 +0200 Received: from 89-172-59-239.adsl.net.t-com.hr ([89.172.59.239]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 13 Aug 2007 03:06:38 +0200 Received: from ivoras by 89-172-59-239.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 13 Aug 2007 03:06:38 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Mon, 13 Aug 2007 03:06:16 +0200 Lines: 128 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig995DCC39F335D2C2CF8092D9" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-59-239.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) X-Enigmail-Version: 0.94.3.0 Sender: news Subject: Gvirstor "newfs" problem - help needed 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, 13 Aug 2007 01:06:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig995DCC39F335D2C2CF8092D9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I have a problem with gvirstor and it looks like I need help (or at least fresh ideas) with it. About a month ago Pawel found that he couldn't newfs huge gvirstor devices - newfs fails when rereading the superblock it has written a moment ago (the read signature apparently doesn't match). I confirmed this and found that it also happens on not-so-large gvirstor devices. One specific case is a device of 1100000 MB with 2048 KB-sized chunks. This is what's happening: - The following is the dump of IO operations from newfs. It first writes some data, probably including the superblock: Jul 18 05:12:01 gv7 kernel: GEOM_VIRSTOR[10]: Mapped W(1153467153920, 512) to (550015,2096640,512) (((note: the above log entry says someone is writing on virtual offset 1153467153920, size 512, and this is mapped to virtual chunk #550015, in-chunk offset 2096640))) Jul 18 05:12:01 gv7 kernel: GEOM_VIRSTOR[10]: Allocated chunk 1 on da0 for virstor/bla Jul 18 05:12:01 gv7 kernel: GEOM_VIRSTOR[10]: Mapped R(8192, 8192) to (0,8192,8192) Jul 18 05:12:01 gv7 kernel: GEOM_VIRSTOR[10]: Mapped W(65536, 8192) to (0,65536,8192) Jul 18 05:12:01 gv7 kernel: GEOM_VIRSTOR[10]: Mapped W(81920, 65536) to (0,81920,65536) Jul 18 05:12:01 gv7 kernel: GEOM_VIRSTOR[10]: Mapped W(192774144, 65536) to (91,1933312,65536) The important operation is the semi-last one: a write to position 81920 of size 65536. - Following this, there's a long list of writes of UFS metadata of size 65536, scattered across the drive in increasing offset and not important. This IO looks like: Jul 18 05:12:01 gv7 kernel: GEOM_VIRSTOR[10]: Allocated chunk 3 on da0 for virstor/bla Jul 18 05:12:01 gv7 kernel: GEOM_VIRSTOR[10]: Mapped W(385466368, 65536) to (183,1687552,65536) Jul 18 05:12:01 gv7 kernel: GEOM_VIRSTOR[10]: Allocated chunk 4 on da0 for virstor/bla Jul 18 05:12:01 gv7 kernel: GEOM_VIRSTOR[10]: Mapped W(578158592, 65536) to (275,1441792,65536) - Finally, newfs reads some of the metadata it has written at the start: Jul 18 05:12:45 gv7 kernel: GEOM_VIRSTOR[10]: Mapped R(98304, 16384) to (0,98304,16384) THIS request returns something newfs doesn't like. This data is within the position written by newfs at position 81920. BUT, I cannot reproduce this with my test programs. I made a test program specifically to s(t)imulate this exact behaviour. It writes the block as written by newfs and then reads subblocks from it, eventually creating the same situation: Jul 18 05:14:57 gv7 kernel: GEOM_VIRSTOR[10]: Mapped W(81920, 65536) to (0,81920,65536) =2E.. Jul 18 05:14:57 gv7 kernel: GEOM_VIRSTOR[10]: Mapped R(98304, 16384) to (0,98304,16384) The data written is generated by /dev/random and compared byte for byte with the read data. There are no errors. Between read and write operations in the test program, the program writes to random high locations on the drive, allocating new chunks like newfs does. I've also made several more-or-less generic tests that test "edge" cases like on the border of chunks, random IO, etc, and all pass. The development tree is at http://ivoras.sharanet.org/stuff/gvirstor-devel.tg= z . This tree works only on 7-CURRENT, and has a lot of debugging messages turned on. To run it, run "make", "make so" and "make tests", load the resulting .ko, and make a symlink of the .so file into /lib/geom. To provoke the bug, create a virstor device like this: =2E/gvirstor label -s 1100000 -m 2048 bla /dev/da0 then, simply run "newfs" on it: newfs /dev/virstor/bla To make this work, you'll need lots of space on the physical device (da0 in the above example), something like 50 GB. After newfs finishes writing cgs all over the device, it will read the first superblock and fail in verifying the signature. I've also tried this with ext2's mkfs and fsck, and the same symptom happens, so I don't think there's a bug in newfs: cg 0: bad magic number There are now 5 small test programs in the above source tgz, but all of the tests pass without problems. I'm out of ideas currently, and I'm looking for ideas and advice on how to proceed (I'd like to provoke this bug in a small, managable test case). --------------enig995DCC39F335D2C2CF8092D9 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.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGv66OldnAQVacBcgRAjFeAKCMPvksJ2BN0O+cfKLQDjJV03VvqQCfZacN wldaF1C5+PbNgV0LV2+W5CI= =R18O -----END PGP SIGNATURE----- --------------enig995DCC39F335D2C2CF8092D9-- From owner-freebsd-geom@FreeBSD.ORG Mon Aug 13 06:05:35 2007 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1ED1B16A419 for ; Mon, 13 Aug 2007 06:05:35 +0000 (UTC) (envelope-from arne_woerner@yahoo.com) Received: from web30306.mail.mud.yahoo.com (web30306.mail.mud.yahoo.com [209.191.69.68]) by mx1.freebsd.org (Postfix) with SMTP id C10ED13C459 for ; Mon, 13 Aug 2007 06:05:34 +0000 (UTC) (envelope-from arne_woerner@yahoo.com) Received: (qmail 5080 invoked by uid 60001); 13 Aug 2007 06:05:34 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=hLiO/8Ws/L4yzX+vli3offaGtAeAjfSFett91CKPr8kamvuz9vH1tHDWZOczzgJo6pYiqiuOVibOPu+RYlMfWBhp9LV37WhwHdlNgjjga2UcDsHA6t7tz64KhWgFyF/b0gOayrdLZk6sGqDm41mn+i/Lu6uG+UrM5Ql1Rme1KCI=; X-YMail-OSG: k0whuIwVM1lzz9xX_slD6xRj9BxsZ9.yo3ffYc_4kWPBpH4jl0F_WWENYl8zSM5rufzEVmP_p3EVFj7HZm80_AERtzaGrlFr5X_o6Y8FSPLTj1pFwVR1wIIy4g6wkA-- Received: from [84.141.70.62] by web30306.mail.mud.yahoo.com via HTTP; Sun, 12 Aug 2007 23:05:33 PDT Date: Sun, 12 Aug 2007 23:05:33 -0700 (PDT) From: Arne "Wörner" To: Ivan Voras , freebsd-geom@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <31903.4141.qm@web30306.mail.mud.yahoo.com> Cc: Subject: Re: Gvirstor "newfs" problem - help needed 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, 13 Aug 2007 06:05:35 -0000 Hi! --- Ivan Voras wrote: > cg 0: bad magic number > I know that message from my tests with graid5... It was clearly caused by a bug in graid5, but I cannot remember when or why it happened... I would guess, it happened because of some cache or request-sorting mismanagement (the write didnt take place but the read was executed; or the second write took place before the first write)... Is that possible in gvirstor? Does newfs create such a request-pattern (overlapping write requests <-- would be a little bit astonishing)? But I can definitely say, that it was a bug in graid5... Just my 2 pennies... Bye Arne ____________________________________________________________________________________ Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/ From owner-freebsd-geom@FreeBSD.ORG Mon Aug 13 09:15:30 2007 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16BD216A419 for ; Mon, 13 Aug 2007 09:15:30 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from merke.itea.ntnu.no (merke.itea.ntnu.no [129.241.7.61]) by mx1.freebsd.org (Postfix) with ESMTP id CA45613C465 for ; Mon, 13 Aug 2007 09:15:29 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from localhost (localhost [127.0.0.1]) by merke.itea.ntnu.no (Postfix) with ESMTP id 9202D140222; Mon, 13 Aug 2007 11:15:27 +0200 (CEST) Received: from caracal.stud.ntnu.no (caracal.stud.ntnu.no [129.241.56.185]) by merke.itea.ntnu.no (Postfix) with ESMTP; Mon, 13 Aug 2007 11:14:23 +0200 (CEST) Received: by caracal.stud.ntnu.no (Postfix, from userid 2312) id C2FF96240E2; Mon, 13 Aug 2007 11:14:06 +0200 (CEST) Date: Mon, 13 Aug 2007 11:14:06 +0200 From: Ulf Lilleengen To: freebsd-geom@freebsd.org Message-ID: <20070813091406.GA3078@stud.ntnu.no> References: <46BE65EC.1050906@queue.to> <46BE79AE.2070007@cyberleo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46BE79AE.2070007@cyberleo.net> User-Agent: Mutt/1.5.9i X-Content-Scanned: with sophos and spamassassin at mailgw.ntnu.no. Cc: Howard Goldstein , CyberLeo Kitsana Subject: Re: graid5 or gvinums - bootable? 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, 13 Aug 2007 09:15:30 -0000 On Sat, Aug 11, 2007 at 10:08:07PM -0500, CyberLeo Kitsana wrote: > Howard Goldstein wrote: > > Q: Should a graid5 or gvinum provider be expected to be bootable, > > assuming the prover's partition table has an active bootable partition > > containing a properly bsdlabeled 'a' slice with the /boot subdirectories > > in it (i.e., all of the stuff you normally need in an ordinary, non-geom > > system to have a bootable slice)? > > > > Teh googling is somewhat helpful indicating that the boot loader can now > > deal with the GEOM'd gvinum as the boot device, and of course it works > > with gmirror but that's not really surprising since that provider > > wouldn't doesn't have its /boot slice striped into ribbons across > > multiple consumers like graid5 and gvinum in raid-5. > > I haven't tried with just /boot, but I have a machine with a 1.5GB > mirror across four disks for the root filesystem, with a graid5 across > the remaining space for the other filesystems. That works just fine. > > As far as I know, however, no boot loader can understand > software-striped or software-raid5ed filesystems, given that it would > essentially need to implement the relevant geom providers itself. > Yes. This is no problem with mirrors, since it's essentially just to read the first sectors of it. However, the other reason is that gmirror stores it's metadata at the end, so the loader won't have to care about it. So, booting of a gvinum volume will not work, but using another partition for /boot, and gvinum for root should work. -- Ulf Lilleengen From owner-freebsd-geom@FreeBSD.ORG Mon Aug 13 11:00:06 2007 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA07216A419 for ; Mon, 13 Aug 2007 11:00:06 +0000 (UTC) (envelope-from cyberleo@cyberleo.net) Received: from pizzabox.cyberleo.net (alpha.cyberleo.net [198.145.45.10]) by mx1.freebsd.org (Postfix) with ESMTP id A3FC913C45B for ; Mon, 13 Aug 2007 11:00:06 +0000 (UTC) (envelope-from cyberleo@cyberleo.net) Received: (qmail 85076 invoked from network); 13 Aug 2007 11:00:05 -0000 Received: from adsl-75-3-83-251.dsl.chcgil.sbcglobal.net (HELO ?172.16.44.14?) (cyberleo@cyberleo.net@75.3.83.251) by alpha.cyberleo.net with ESMTPA; 13 Aug 2007 11:00:05 -0000 Message-ID: <46C033E0.5050203@cyberleo.net> Date: Mon, 13 Aug 2007 05:34:49 -0500 From: CyberLeo Kitsana User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Ulf Lilleengen References: <46BE65EC.1050906@queue.to> <46BE79AE.2070007@cyberleo.net> <20070813091406.GA3078@stud.ntnu.no> In-Reply-To: <20070813091406.GA3078@stud.ntnu.no> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Howard Goldstein , freebsd-geom@freebsd.org Subject: Re: graid5 or gvinums - bootable? 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, 13 Aug 2007 11:00:06 -0000 Ulf Lilleengen wrote: > Yes. This is no problem with mirrors, since it's essentially just to read the > first sectors of it. However, the other reason is that gmirror stores it's > metadata at the end, so the loader won't have to care about it. So, booting of a > gvinum volume will not work, but using another partition for /boot, and gvinum for > root should work. With linux, I would agree, and indeed have several machines set up in this very fashion. However, FreeBSD appears to make too many assumptions about what resides where to make this a viable option, such as only booting from the 'a' partition, and then subsequently mounting it as / regardless of the contents of the fstab. Though, you might be able to get away with it by creating a fake root and init in mfsroot or elsewhere that contains just enough logic to load modules, build arrays, and then mount the real root and exec the real init. Sounds like a pain, though. -- Fuzzy love, -CyberLeo Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net Furry Peace! - http://wwww.fur.com/peace/ From owner-freebsd-geom@FreeBSD.ORG Mon Aug 13 11:08:19 2007 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F73B16A419 for ; Mon, 13 Aug 2007 11:08:19 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2E05F13C4B4 for ; Mon, 13 Aug 2007 11:08:19 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l7DB8JVQ047676 for ; Mon, 13 Aug 2007 11:08:19 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l7DB8Hgp047672 for freebsd-geom@FreeBSD.org; Mon, 13 Aug 2007 11:08:17 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 13 Aug 2007 11:08:17 GMT Message-Id: <200708131108.l7DB8Hgp047672@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-geom@FreeBSD.org Cc: Subject: Current problem reports assigned to 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, 13 Aug 2007 11:08:19 -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 o kern/113419 geom [geom] geom fox multipathing not failing back o misc/113543 geom [geom] [patch] geom(8) utilities don't work inside the o kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad 13 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 o kern/113790 geom [patch] enable the Camellia block cipher on GEOM ELI ( o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113885 geom [geom] [patch] improved gmirror balance algorithm o kern/114532 geom GEOM_MIRROR shows up in kldstat even if compiled in th 10 problems total. From owner-freebsd-geom@FreeBSD.ORG Mon Aug 13 12:13:18 2007 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 960BD16A46B for ; Mon, 13 Aug 2007 12:13:18 +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 1E41713C461 for ; Mon, 13 Aug 2007 12:13:17 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IKYn9-0002I7-Up for freebsd-geom@freebsd.org; Mon, 13 Aug 2007 14:13:04 +0200 Received: from 78-1-99-156.adsl.net.t-com.hr ([78.1.99.156]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 13 Aug 2007 14:13:03 +0200 Received: from ivoras by 78-1-99-156.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 13 Aug 2007 14:13:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Mon, 13 Aug 2007 14:12:50 +0200 Lines: 51 Message-ID: References: <31903.4141.qm@web30306.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig47597366338E2A7A8FF6BBAD" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-99-156.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) In-Reply-To: <31903.4141.qm@web30306.mail.mud.yahoo.com> X-Enigmail-Version: 0.94.3.0 Sender: news Subject: Re: Gvirstor "newfs" problem - help needed 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, 13 Aug 2007 12:13:18 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig47597366338E2A7A8FF6BBAD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Arne W=F6rner wrote: > Hi! >=20 > --- Ivan Voras wrote: >> cg 0: bad magic number >> > I know that message from my tests with graid5... > It was clearly caused by a bug in graid5, but I cannot remember when or= why it > happened... > I would guess, it happened because of some cache or request-sorting > mismanagement (the write didnt take place but the read was executed; or= the > second write took place before the first write)... Is that possible in > gvirstor? Does newfs create such a request-pattern (overlapping write r= equests > <-- would be a little bit astonishing)? >=20 > But I can definitely say, that it was a bug in graid5... Thanks for replying! gvirstor doesn't reorder IO and i doesn't have a cache, so it's not that. I agree that it's almost certainly a bug in gvirstor. The only "slightly unusual" thing newfs does is that it first writes a "big" block, then reads a smaller block from within the written big block and doesn't like what it gets. But this scenario is well tested by my test cases and I don't see why it fails for newfs. --------------enig47597366338E2A7A8FF6BBAD 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.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGwErCldnAQVacBcgRAlOzAKCsGfuSOGWvvOqpqaNuaj6P015mnQCgrK5d s/xLmtfrk0mFc2XKWS280bY= =6nYt -----END PGP SIGNATURE----- --------------enig47597366338E2A7A8FF6BBAD-- From owner-freebsd-geom@FreeBSD.ORG Mon Aug 13 17:33:27 2007 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8322316A420 for ; Mon, 13 Aug 2007 17:33:27 +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 E8D1313C45B for ; Mon, 13 Aug 2007 17:33:26 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 4DFDF487F8; Mon, 13 Aug 2007 19:15:21 +0200 (CEST) Received: from localhost (public-gprs36066.centertel.pl [91.94.12.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id E8A0E45CD9; Mon, 13 Aug 2007 19:15:06 +0200 (CEST) Date: Mon, 13 Aug 2007 19:14:01 +0200 From: Pawel Jakub Dawidek To: Ivan Voras Message-ID: <20070813171401.GA8819@garage.freebsd.pl> References: <31903.4141.qm@web30306.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=BAYES_00,RCVD_IN_NJABL_DUL autolearn=no version=3.0.4 Cc: freebsd-geom@freebsd.org Subject: Re: Gvirstor "newfs" problem - help needed 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, 13 Aug 2007 17:33:27 -0000 --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 13, 2007 at 02:12:50PM +0200, Ivan Voras wrote: > Arne W=F6rner wrote: > > Hi! > >=20 > > --- Ivan Voras wrote: > >> cg 0: bad magic number > >> > > I know that message from my tests with graid5... > > It was clearly caused by a bug in graid5, but I cannot remember when or= why it > > happened... > > I would guess, it happened because of some cache or request-sorting > > mismanagement (the write didnt take place but the read was executed; or= the > > second write took place before the first write)... Is that possible in > > gvirstor? Does newfs create such a request-pattern (overlapping write r= equests > > <-- would be a little bit astonishing)? > >=20 > > But I can definitely say, that it was a bug in graid5... >=20 > Thanks for replying! gvirstor doesn't reorder IO and i doesn't have a > cache, so it's not that. I agree that it's almost certainly a bug in > gvirstor. >=20 > The only "slightly unusual" thing newfs does is that it first writes a > "big" block, then reads a smaller block from within the written big > block and doesn't like what it gets. But this scenario is well tested by > my test cases and I don't see why it fails for newfs. Ivan, try to configure gvirstor on top of gnop. Modify gnop to log only requests between 81920 and 147456 (81920 + 65536). Something like: if ((bp->bio_offset >=3D 81920 && bp->bio_offset < 147456) || (bp->bio_offset + bp->bio_length >=3D 81920 && bp->bio_offset + bp->bio_length < 147456)) { G_NOP_LOGREQ(bp, "Request."); } Run newfs and watch which gvirstor I/O request triggers request into this area - my guess is that gvirstor recalculates something incorrectly and instead of writting somewhere else it writes into this very place. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --ew6BAiZeqk4r7MaW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGwJFZForvXbEpPzQRAuKdAKCP+6v6rVdVfA21jRIwoth2QYEUEgCg1O7K lo7h3RwFK10hHsKTTMlkrN8= =NSgv -----END PGP SIGNATURE----- --ew6BAiZeqk4r7MaW-- From owner-freebsd-geom@FreeBSD.ORG Mon Aug 13 20:40:39 2007 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E254E16A41A; Mon, 13 Aug 2007 20:40:39 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from signal.itea.ntnu.no (signal.itea.ntnu.no [129.241.190.231]) by mx1.freebsd.org (Postfix) with ESMTP id 9A1B013C461; Mon, 13 Aug 2007 20:40:39 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from localhost (localhost [127.0.0.1]) by signal.itea.ntnu.no (Postfix) with ESMTP id A49AD34A20; Mon, 13 Aug 2007 22:40:37 +0200 (CEST) Received: from gaupe.stud.ntnu.no (gaupe.stud.ntnu.no [129.241.56.184]) by signal.itea.ntnu.no (Postfix) with ESMTP; Mon, 13 Aug 2007 22:40:35 +0200 (CEST) Received: by gaupe.stud.ntnu.no (Postfix, from userid 2312) id DB455D0046; Mon, 13 Aug 2007 22:40:35 +0200 (CEST) Date: Mon, 13 Aug 2007 22:40:35 +0200 From: Ulf Lilleengen To: freebsd-current@freebsd.org, freebsd-geom@freebsd.org, freebsd-arch@freebsd.org Message-ID: <20070813204035.GA5338@stud.ntnu.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Content-Scanned: with sophos and spamassassin at mailgw.ntnu.no. Cc: le@FreeBSD.org Subject: Testers wanted: Gvinum patches of SoC 2007 work 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, 13 Aug 2007 20:40:40 -0000 Hi, It's here! The new and hopefully better gvinum patch. This is perhaps my final patch of the work I've done during GSoC 2007 (the patch will be updated when I fix a bug). This doesn't mean I'll stop work on gvinum, but rather that I'm not adding more features until this gets into the tree. But, for this to get into the tree, I need people to test it. _ALL_ reports on how it works is good. So, what should you test? * Plain normal use. * Mirror synchronization, rebuild if raid-5 arrays, growing of raid-5 arrays etc. These should work, and probably is the most tested, but some weird combinations that I have not forseen might show itself. * Try weird combinations to check if it crashes. * Test mirror, concat, stripe and raid5 commands. * If there are any issues with the usability aspect. E.g. if the information gvinum gives you is good enough for you to understand what it's doing, if one way to do things seems unnatural to you etc. I'd like to hear all of this, no matter how bikshedish it might sound, it might be something that have been overlooked. These things are hard to test for the people that have been developing it, since we know how it "should" be used. Before you head on, beware that the new gvinum does not give messages back to the userland gvinum (so you won't get them into your terminal). This is because it's not very simple to do with the new event system. !! This means you'll have to look after messages in /var/log/messages !! And thanks to people for comments and help that I've been getting during the summer. -- Ulf Lilleengen From owner-freebsd-geom@FreeBSD.ORG Mon Aug 13 20:47:19 2007 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0CEF16A417; Mon, 13 Aug 2007 20:47:19 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from fri.itea.ntnu.no (fri.itea.ntnu.no [129.241.7.60]) by mx1.freebsd.org (Postfix) with ESMTP id 8865713C494; Mon, 13 Aug 2007 20:47:19 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from localhost (localhost [127.0.0.1]) by fri.itea.ntnu.no (Postfix) with ESMTP id 10CA6868F; Mon, 13 Aug 2007 22:46:55 +0200 (CEST) Received: from gaupe.stud.ntnu.no (gaupe.stud.ntnu.no [129.241.56.184]) by fri.itea.ntnu.no (Postfix) with ESMTP; Mon, 13 Aug 2007 22:46:51 +0200 (CEST) Received: by gaupe.stud.ntnu.no (Postfix, from userid 2312) id DACCFD0046; Mon, 13 Aug 2007 22:46:51 +0200 (CEST) Date: Mon, 13 Aug 2007 22:46:51 +0200 From: Ulf Lilleengen To: freebsd-current@freebsd.org, freebsd-geom@freebsd.org, freebsd-arch@freebsd.org Message-ID: <20070813204651.GB5338@stud.ntnu.no> References: <20070813204035.GA5338@stud.ntnu.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070813204035.GA5338@stud.ntnu.no> User-Agent: Mutt/1.5.9i X-Content-Scanned: with sophos and spamassassin at mailgw.ntnu.no. Cc: le@FreeBSD.org Subject: Re: Testers wanted: Gvinum patches of SoC 2007 work 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, 13 Aug 2007 20:47:20 -0000 On man, aug 13, 2007 at 10:40:35 +0200, Ulf Lilleengen wrote: > Hi, > > It's here! The new and hopefully better gvinum patch. This is perhaps my final > patch of the work I've done during GSoC 2007 (the patch will be updated when I > fix a bug). This doesn't mean I'll stop work on gvinum, but rather that I'm not > adding more features until this gets into the tree. But, for this to get into > the tree, I need people to test it. _ALL_ reports on how it works is good. > *SNIP* > Ehm, And ofcourse, the patches can be found here: http://folk.ntnu.no/lulf/patches/freebsd/gvinum One for releng_6* and one for current. The patch is applied like this: # cd /usr/src && patch < /path/to/patch Remember to not have the old gvinum module running. Then install the module: # cd /usr/src/sys/modules/geom/geom_vinum && make && make install clean Then install userland gvinum # cd /usr/src/sbin/gvinum && make && make install clean And you should be ready to go. The updated manpage in /usr/src/sbin/gvinum/gvinum.8 describes how growing is done. Just gzip it and put it in /usr/share/man/man8 to use it. -- Ulf Lilleengen From owner-freebsd-geom@FreeBSD.ORG Tue Aug 14 00:19:32 2007 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6821616A419 for ; Tue, 14 Aug 2007 00:19:32 +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 DF82D13C45D for ; Tue, 14 Aug 2007 00:19:31 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IKk84-0006S2-Ll for freebsd-geom@freebsd.org; Tue, 14 Aug 2007 02:19:24 +0200 Received: from 89-172-63-69.adsl.net.t-com.hr ([89.172.63.69]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Aug 2007 02:19:24 +0200 Received: from ivoras by 89-172-63-69.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Aug 2007 02:19:24 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Tue, 14 Aug 2007 02:19:05 +0200 Lines: 31 Message-ID: References: <31903.4141.qm@web30306.mail.mud.yahoo.com> <20070813171401.GA8819@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFC02235377A4412E86CFF5B4" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-63-69.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) In-Reply-To: <20070813171401.GA8819@garage.freebsd.pl> X-Enigmail-Version: 0.94.3.0 Sender: news Subject: Re: Gvirstor "newfs" problem - help needed 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, 14 Aug 2007 00:19:32 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFC02235377A4412E86CFF5B4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pawel Jakub Dawidek wrote: > Run newfs and watch which gvirstor I/O request triggers request into > this area - my guess is that gvirstor recalculates something incorrectl= y > and instead of writting somewhere else it writes into this very place. Your guess was right - because of a trivial error data was being written in the middle of the allocation table. --------------enigFC02235377A4412E86CFF5B4 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.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGwPT/ldnAQVacBcgRAvGoAKCrU5qhQy3PPr5APPHKONWGkNFdZwCg5/8Q 1QUMPbcJ7qxMisbb7wow8nI= =0NWs -----END PGP SIGNATURE----- --------------enigFC02235377A4412E86CFF5B4-- From owner-freebsd-geom@FreeBSD.ORG Tue Aug 14 04:45:16 2007 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E32FB16A417 for ; Tue, 14 Aug 2007 04:45:16 +0000 (UTC) (envelope-from hg@queue.to) Received: from pickle.queue.to (pickle.queue.to [71.180.69.18]) by mx1.freebsd.org (Postfix) with ESMTP id 5459813C428 for ; Tue, 14 Aug 2007 04:45:16 +0000 (UTC) (envelope-from hg@queue.to) Received: (qmail 51728 invoked from network); 14 Aug 2007 00:45:15 -0400 Received: from cally.queue.to (172.16.0.6) by pickle.queue.to with ESMTP; 14 Aug 2007 00:45:15 -0400 Message-ID: <46C1335A.2000008@queue.to> Date: Tue, 14 Aug 2007 00:45:14 -0400 From: Howard Goldstein User-Agent: Thunderbird 2.0.0.6 (X11/20070802) MIME-Version: 1.0 To: Ulf Lilleengen , cyberleo@cyberleo.net References: <46BE65EC.1050906@queue.to> <46BE79AE.2070007@cyberleo.net> <20070813091406.GA3078@stud.ntnu.no> In-Reply-To: <20070813091406.GA3078@stud.ntnu.no> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-geom@freebsd.org Subject: RESOLVED - Re: graid5 or gvinums - bootable? 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, 14 Aug 2007 04:45:17 -0000 Ulf Lilleengen wrote: > On Sat, Aug 11, 2007 at 10:08:07PM -0500, CyberLeo Kitsana wrote: >> Howard Goldstein wrote: >>> Q: Should a graid5 or gvinum provider be expected to be bootable, >>> assuming the prover's partition table has an active bootable partition >>> containing a properly bsdlabeled 'a' slice with the /boot subdirectories >>> in it (i.e., all of the stuff you normally need in an ordinary, non-geom >>> system to have a bootable slice)? >>> >>> Teh googling is somewhat helpful indicating that the boot loader can now >>> deal with the GEOM'd gvinum as the boot device, and of course it works >>> with gmirror but that's not really surprising since that provider >>> wouldn't doesn't have its /boot slice striped into ribbons across >>> multiple consumers like graid5 and gvinum in raid-5. >> I haven't tried with just /boot, but I have a machine with a 1.5GB >> mirror across four disks for the root filesystem, with a graid5 across >> the remaining space for the other filesystems. That works just fine. >> >> As far as I know, however, no boot loader can understand >> software-striped or software-raid5ed filesystems, given that it would >> essentially need to implement the relevant geom providers itself. >> > Yes. This is no problem with mirrors, since it's essentially just to read the > first sectors of it. However, the other reason is that gmirror stores it's > metadata at the end, so the loader won't have to care about it. So, booting of a > gvinum volume will not work, but using another partition for /boot, and gvinum for > root should work. What I eventually did here across three identical 320gb drives was to set up three slices on all of the drives s1 gmirror for / s2 gstripe for swap and /tmp s3 graid5 for /var and /usr I ran into a problem though, the geometry of the onboard ICH5 RAID controlling two of the drives turned out to be different than the 3ware Escalade's geometry for the same drive. This seems to have caused the 3ware controller to do unaligned i/o with a performance hit I didn't notice until it also caused intermittent warnings for the 3ware driver when its malloc failed. Setting up the stripes so they all began on cylinder boundaries for both geometries appears to have worked (at least it's initializing the graid5 array about twice as fast as when it was unaligned) I wonder if I could have avoided a lot of annoying arithmetic with looooong integers if I set the consumers up on the partitions in a single but it seemed a bridge too far Thanks Cyberleo and Ulf for your observations and comments From owner-freebsd-geom@FreeBSD.ORG Wed Aug 15 18:33:47 2007 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0900216A41A; Wed, 15 Aug 2007 18:33:47 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D0D8113C45B; Wed, 15 Aug 2007 18:33:46 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l7FIXkCl074002; Wed, 15 Aug 2007 18:33:46 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l7FIXkB2073998; Wed, 15 Aug 2007 18:33:46 GMT (envelope-from linimon) Date: Wed, 15 Aug 2007 18:33:46 GMT Message-Id: <200708151833.l7FIXkB2073998@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-geom@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/115547: [geom] [patch] for GEOM Eli to get password from stdin (useful for non-interactive scripting) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 18:33:47 -0000 Synopsis: [geom] [patch] for GEOM Eli to get password from stdin (useful for non-interactive scripting) Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: linimon Responsible-Changed-When: Wed Aug 15 18:33:39 UTC 2007 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=115547 From owner-freebsd-geom@FreeBSD.ORG Fri Aug 17 22:08:18 2007 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F2A116A41A; Fri, 17 Aug 2007 22:08:18 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2364A13C49D; Fri, 17 Aug 2007 22:08:18 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l7HM8Iku059441; Fri, 17 Aug 2007 22:08:18 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l7HM8HRl059436; Fri, 17 Aug 2007 22:08:17 GMT (envelope-from linimon) Date: Fri, 17 Aug 2007 22:08:17 GMT Message-Id: <200708172208.l7HM8HRl059436@freefall.freebsd.org> To: gbradley@rocketmail.com, linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-geom@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/115572: [gbde] gbde partitions fail at 28bit/48bit LBA addressing boundary 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, 17 Aug 2007 22:08:18 -0000 Synopsis: [gbde] gbde partitions fail at 28bit/48bit LBA addressing boundary State-Changed-From-To: feedback->open State-Changed-By: linimon State-Changed-When: Fri Aug 17 22:07:57 UTC 2007 State-Changed-Why: Feedback received. Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: linimon Responsible-Changed-When: Fri Aug 17 22:07:57 UTC 2007 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=115572 From owner-freebsd-geom@FreeBSD.ORG Fri Aug 17 22:10:07 2007 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CF1716A417 for ; Fri, 17 Aug 2007 22:10:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2346313C480 for ; Fri, 17 Aug 2007 22:10:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l7HMA6bm059638 for ; Fri, 17 Aug 2007 22:10:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l7HMA6QS059637; Fri, 17 Aug 2007 22:10:06 GMT (envelope-from gnats) Date: Fri, 17 Aug 2007 22:10:06 GMT Message-Id: <200708172210.l7HMA6QS059637@freefall.freebsd.org> To: freebsd-geom@FreeBSD.org From: linimon@lonesome.com (Mark Linimon) Cc: Subject: Re: kern/115572: [gbde] gbde partitions fail at 28bit/48bit LBA addressing boundary X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mark Linimon List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 22:10:07 -0000 The following reply was made to PR kern/115572; it has been noted by GNATS. From: linimon@lonesome.com (Mark Linimon) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/115572: [gbde] gbde partitions fail at 28bit/48bit LBA addressing boundary Date: Fri, 17 Aug 2007 17:07:23 -0500 ----- Forwarded message from Graham ----- Sorry, but my only solution at the moment is to use geli ! We should not guess at the cause, I know, but I am writing chunks in succession to a newly gbde initialised drive, checking access after each shot, with the intent of narrowing down to the specific write which causes the damage --- i.e. the next read and write at the 28/48 boundary fails. This may take a little time, but I'd like to find a small specific write block address which does the damage. It will then be easier (with a specific case) to work through the block address mapping which ghappens in gbde. Then maybe a fix....hope this strategy is ok. On an optimistic note --- if we can pin this down, it may help explain some of the other gbde corruption cases in the bug list. I will keep you posted as soon as I can find a small, specific case which causes the problem. regards Graham ----- End forwarded message ----- From owner-freebsd-geom@FreeBSD.ORG Fri Aug 17 22:10:14 2007 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C272E16A469 for ; Fri, 17 Aug 2007 22:10:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6D49013C4B7 for ; Fri, 17 Aug 2007 22:10:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l7HMABKU059698 for ; Fri, 17 Aug 2007 22:10:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l7HMABfI059697; Fri, 17 Aug 2007 22:10:11 GMT (envelope-from gnats) Date: Fri, 17 Aug 2007 22:10:11 GMT Message-Id: <200708172210.l7HMABfI059697@freefall.freebsd.org> To: freebsd-geom@FreeBSD.org From: linimon@lonesome.com (Mark Linimon) Cc: Subject: Re: kern/115572: [gbde] gbde partitions fail at 28bit/48bit LBA addressing boundary X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mark Linimon List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 22:10:14 -0000 The following reply was made to PR kern/115572; it has been noted by GNATS. From: linimon@lonesome.com (Mark Linimon) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/115572: [gbde] gbde partitions fail at 28bit/48bit LBA addressing boundary Date: Fri, 17 Aug 2007 17:07:53 -0500 ----- Forwarded message from Graham ----- further to yesterday, I run this sequence... 1. init and attach a gbde volume, 2. write zeros from start of the volume, in 1GiB bursts, until dd hits an i/o error, 3. detach gbde volume this error came after 121GiB written. Then I have run a repeated sequence of... 1. init and attach a gbde volume, 2. write using dd 1GiB of zeros starting 121 GiB into the device 3. detach gbde volume like this..... #! /usr/local/bin/bash # trap 'gbde detach ad4;exit 9' 1 2 3 13 15 # while [ 0 -eq 0 ] do gbde init ad4 -P password gbde attach ad4 -p password START=1982464 COUNT=16384 dd if=/dev/zero of=/dev/ad4.bde bs=64k oseek=$START count=$COUNT gbde detach ad4 done exit 3 # (and then I checked smartctl for no errors on the drive.) which gives an i/o error at different block counts, always with an LBA at or more often just a few sectors below the LBA=268435455 The gbde-volume block offsets at error are much more varied, and a significant proportion of the tests do not show errors in this test. I have read the paper by Poul-Henning Kamp "GBDE-GEOM Disk Based Encryption" and it is clear that the gbde volume's sector addresses are mapped on the physical drive in a non-repeatable way each time "init" takes place. This explains the movable nature of the error, and the symptoms perceived by the user when a filesystem is written in geom can vary according to whether the tripwire LBA address gets mapped to data, inodes, or superblock. I am afraid this sounds much like a mapping consistency issue in GBDE, the mapping is quite complex, and I expect there are others better placed to know where to look for it. I am happy to help if you wish, there is a long-standing issue here needs fixing, but I would need a prompt towards finding the code which implements the mapping. regards Graham ----- End forwarded message ----- From owner-freebsd-geom@FreeBSD.ORG Sat Aug 18 21:20:12 2007 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D99E16A473 for ; Sat, 18 Aug 2007 21:20:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EA4BF13C4B3 for ; Sat, 18 Aug 2007 21:20:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l7ILKBMV046100 for ; Sat, 18 Aug 2007 21:20:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l7ILKBvF046099; Sat, 18 Aug 2007 21:20:11 GMT (envelope-from gnats) Date: Sat, 18 Aug 2007 21:20:11 GMT Message-Id: <200708182120.l7ILKBvF046099@freefall.freebsd.org> To: freebsd-geom@FreeBSD.org From: Graham Cc: Subject: Re: kern/115572: [gbde] gbde partitions fail at 28bit/48bit LBA addressing boundary X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Graham List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2007 21:20:12 -0000 The following reply was made to PR kern/115572; it has been noted by GNATS. From: Graham To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/115572: [gbde] gbde partitions fail at 28bit/48bit LBA addressing boundary Date: Sat, 18 Aug 2007 13:49:13 -0700 (PDT) I have stripped this problem down to its simplest form, which is that a block read or write where the block straddles the 137gb boundary fails. Simplest reproducible form: 1. create a single partition on a large drive, so then the first partition starts at a sector offset of 1. In my case this is /dev/ad4s1. 2. attempt (say).... rabbit# dd if=/dev/zero of=/dev/ad4s1 oseek=2097151 count=1 bs=64k and the result is.... dd: /dev/ad4s1: Input/output error 1+0 records in 0+0 records out 0 bytes transferred in 0.000325 secs (0 bytes/sec) (If dd is performed on the raw drive, /dev/ad4 then block boundary is always a power of 2, and blocksize a smaller power of 2. That's always ok. But we can't assume we use drives that way.) So a transfer which starts in the 28-bit zone, but extends over into the 48-bit region, fails. Such transfers happen in the superblock of certain size drives, and that plays havoc. The sector mapping of gbde can do this, but soft-update gets screwed by this happening. It's not actually to do with the crypto as I first suspected. ____________________________________________________________________________________Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. http://tv.yahoo.com/