From owner-freebsd-geom@FreeBSD.ORG Mon Jan 10 16:36:43 2005 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3065016A4CE for ; Mon, 10 Jan 2005 16:36:43 +0000 (GMT) Received: from visp.engelschall.com (visp.engelschall.com [195.27.176.148]) by mx1.FreeBSD.org (Postfix) with ESMTP id 948CD43D3F for ; Mon, 10 Jan 2005 16:36:42 +0000 (GMT) (envelope-from rse@engelschall.com) Received: by visp.engelschall.com (Postfix, from userid 1005) id 993F24CE56B; Mon, 10 Jan 2005 17:36:55 +0100 (CET) Received: by en1.engelschall.com (Postfix, from userid 10000) id 1756DA17CC; Mon, 10 Jan 2005 17:36:34 +0100 (CET) Date: Mon, 10 Jan 2005 17:36:34 +0100 From: "Ralf S. Engelschall" To: freebsd-geom@freebsd.org Message-ID: <20050110163634.GA47526@engelschall.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Organization: FreeBSD Subject: [HOWTO] FreeBSD system disk mirroring with GEOM X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Ralf S. Engelschall" List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 16:36:43 -0000 FYI: I've prepared a detailed step-by-step command list on how to establish a RAID-1 (mirror) for the system partitions with GEOM and gmirror(8). You can find the resulting HOWTO document under http://people.freebsd.org/~rse/mirror/ -- rse@FreeBSD.org Ralf S. Engelschall FreeBSD.org/~rse rse@engelschall.com FreeBSD committer www.engelschall.com From owner-freebsd-geom@FreeBSD.ORG Tue Jan 11 00:42:24 2005 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AABB016A4CE; Tue, 11 Jan 2005 00:42:24 +0000 (GMT) Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FB8643D1D; Tue, 11 Jan 2005 00:42:23 +0000 (GMT) (envelope-from aw1@stade.co.uk) Received: from alsager-adsl.stade.co.uk ([81.6.222.119] helo=access2.hanley.stade.co.uk) 1.165) id 41e320e7.2e98.69; Tue, 11 Jan 2005 00:42:15 +0000 (envelope-sender ) Received: from titus.hanley.stade.co.uk (titus [192.168.1.5]) j0B0gFnd075595; Tue, 11 Jan 2005 00:42:15 GMT (envelope-from aw1@titus.hanley.stade.co.uk) Received: from titus.hanley.stade.co.uk (localhost [127.0.0.1]) j0B0gF3p077861; Tue, 11 Jan 2005 00:42:15 GMT (envelope-from aw1@titus.hanley.stade.co.uk) Received: (from aw1@localhost)j0B0gEBq077860; Tue, 11 Jan 2005 00:42:14 GMT (envelope-from aw1) Date: Tue, 11 Jan 2005 00:42:14 +0000 From: Adrian Wontroba To: "Ralf S. Engelschall" Message-ID: <20050111004214.A77092@titus.hanley.stade.co.uk> References: <20050110163634.GA47526@engelschall.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20050110163634.GA47526@engelschall.com>; from rse@FreeBSD.org on Mon, Jan 10, 2005 at 05:36:34PM +0100 X-Operating-System: FreeBSD 4.10-STABLE Organization: Oh dear, I've joined one again. cc: freebsd-geom@FreeBSD.org Subject: Re: [HOWTO] FreeBSD system disk mirroring with GEOM X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: aw1@stade.co.uk List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 00:42:24 -0000 On Mon, Jan 10, 2005 at 05:36:34PM +0100, Ralf S. Engelschall wrote: > FYI: I've prepared a detailed step-by-step command list on how to > establish a RAID-1 (mirror) for the system partitions with GEOM and > gmirror(8). You can find the resulting HOWTO document under > http://people.freebsd.org/~rse/mirror/ Looks good, but: It doesn't render too well under Konquerer - the examples are smashed into a single, very long, line vanishing off the right side of the screen. It is more legible with IE, where it just looses the left hand edge. Shouldn't the examples start with "make sure the SECOND disk ..."? Maybe there should be additional comments at tbe bsdlabel -e stage to the effect that this is where you create your partitions, and that it is a good idea to have worked out in advance how big they are to be? Will this make its way into the handbook? -- Adrian Wontroba From owner-freebsd-geom@FreeBSD.ORG Tue Jan 11 01:04:23 2005 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC14B16A4CE for ; Tue, 11 Jan 2005 01:04:23 +0000 (GMT) Received: from koyukuk.teamcool.net (koyukuk.teamcool.net [208.39.216.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D17E43D53 for ; Tue, 11 Jan 2005 01:04:23 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from localhost (localhost [127.0.0.1]) by localhost.teamcool.net (TeamCool Rocks) with SMTP id B5D1C11E66 for ; Mon, 10 Jan 2005 18:04:22 -0700 (MST) Received: from [192.168.1.112] (unknown [192.168.1.112]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id 7294911E64 for ; Mon, 10 Jan 2005 18:04:22 -0700 (MST) Message-ID: <41E3261F.5080503@teamcool.net> Date: Mon, 10 Jan 2005 18:04:31 -0700 From: Ken Gunderson User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-geom@FreeBSD.org References: <20050110163634.GA47526@engelschall.com> <20050111004214.A77092@titus.hanley.stade.co.uk> In-Reply-To: <20050111004214.A77092@titus.hanley.stade.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [HOWTO] FreeBSD system disk mirroring with GEOM X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 01:04:23 -0000 Adrian Wontroba wrote: > On Mon, Jan 10, 2005 at 05:36:34PM +0100, Ralf S. Engelschall wrote: > >>FYI: I've prepared a detailed step-by-step command list on how to >>establish a RAID-1 (mirror) for the system partitions with GEOM and >>gmirror(8). You can find the resulting HOWTO document under >>http://people.freebsd.org/~rse/mirror/ > > > Looks good, but: > > It doesn't render too well under Konquerer - the examples are smashed > into a single, very long, line vanishing off the right side of the > screen. fwiw-- doesn't look too good under Firefox either... But I am sure anything that gets slated to the handbook will be translated to docbook anyhow. Ironically, I was also working on a little howto when this came in. I had a couple q's for Ralf that I posted privately since I didn't want to bother the geom dev heads with, but one area I think merits further elaboration prior to publicaton in the handbook is the inconsistencies between labels created via sysinstall gui and bsdlabel from the command line. They threw me for a bit (until I figured out that they were inconsistent) and I am an experienced sysadmin. A relative newbie to FBSD could easily become confused with bsdlabel -e. Especially if, like many new users, they've tried it from sysinstall gui first. A picture is worth a thousand words, so an actual bsdlable -e session might be nice. Ciao-- kg From owner-freebsd-geom@FreeBSD.ORG Tue Jan 11 11:00:23 2005 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8F7A16A4CE for ; Tue, 11 Jan 2005 11:00:23 +0000 (GMT) Received: from freenix.no (atreides.freenix.no [212.33.142.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2F8D43D2D for ; Tue, 11 Jan 2005 11:00:21 +0000 (GMT) (envelope-from shamz@atreides.freenix.no) Received: from atreides.freenix.no (localhost [127.0.0.1]) by freenix.no (8.12.11/8.12.11) with ESMTP id j0BB0H2v058740 for ; Tue, 11 Jan 2005 12:00:18 +0100 (CET) (envelope-from shamz@atreides.freenix.no) Received: (from shamz@localhost) by atreides.freenix.no (8.12.11/8.12.11/Submit) id j0BB0CBh058739 for freebsd-geom@freebsd.org; Tue, 11 Jan 2005 12:00:12 +0100 (CET) (envelope-from shamz) Date: Tue, 11 Jan 2005 12:00:12 +0100 From: Shaun Jurrens To: freebsd-geom@freebsd.org Message-ID: <20050111110012.GB75478@atreides.freenix.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 4.10-RELEASE-p2 X-Philosophy: If you can read this, you're too close. X-Virus-Scanned: ClamAV 0.80/571/Wed Nov 3 01:15:45 2004 clamav-milter version 0.80j on atreides.freenix.no X-Virus-Status: Clean Subject: partitioning and labeling geom devices X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 11:00:23 -0000 hi all, I'm having problems getting a gstripe "sliced" and "labeled". It's probably that I've messed a step conseptually here somewhere, but I'm sort of a lazy sysinstall weenie when it comes to setting up disks for fbsd, mostly because it always "just worked". I was always presented with a device that I could create slices and partitions on that could be "newfs'd" and mounted. A quick aside before I continue, 'man -k geom' would be more useful if the manpages included 'geom' in the headers... damn hard to find out what's there... What I've done til now: uname -a: FreeBSD paracles 5.3-STABLE FreeBSD 5.3-STABLE #1: Wed Dec 8 16:36:46 CET 2004 (working on a new world now) I've taken 6 9GB disks and created 3 two-disk gmirror devices called plex0, plex1, and plex2 . gmirror label -v -b split -s 2048 plex0 da1 da2 gmirror label -v -b split -s 2048 plex1 da3 da4 gmirror label -v -b split -s 2048 plex2 da5 da6 The devices look like this: paracles:/stand#> ll /dev/mirror/. total 0 crw-r----- 1 root operator 4, 188 Jan 4 18:01 plex0 crw-r----- 1 root operator 4, 189 Jan 4 18:01 plex0a crw-r----- 1 root operator 4, 190 Jan 4 18:01 plex0c crw-r----- 1 root operator 4, 191 Jan 4 18:01 plex1 crw-r----- 1 root operator 4, 200 Jan 4 18:01 plex2 wth there's a plex0a and plex0c, is beyond my comprehension atm... ------------------------------------------------------------- The next step was to create one gstripe using plex[0-2]. This stripe I just called stripe0, for lack of imagination at that point. gstripe label -v -s 1024 stripe0 /dev/mirror/plex0 /dev/mirror/plex1 /dev/mirror/plex2 This seems to have worked as expected. paracles:/stand#> ll /dev/stripe/. total 0 crw-r----- 1 root operator 4, 231 Jan 4 18:01 stripe0 ------------------------------------------------------------- Now I have /dev/stripe/stripe0 and i want to subdivide this into two slices (aka. DOS partitions) and then partition the slices into various FreeBSD partitions, (so the a-h thingies, for those catching up). This is sort of where the concept goes to hell. Sysinstall just barfs literally with 'BARF 269' as error code. Being the lazy sysinstall weenie that I am, this was discouraging. The next step is to dig into the myriad of similar tools in the post geom FreeBSD world to see how one can get the job done. 'fdisk' seemed to be a good place to start, but we also have 'gpt' which almost has a longer BUGS section than description in the manpage. So we run with fdisk... (This gets a bit verbose, but I'm a sysinstall weenie, so bear with me...) ******* Working on device /dev/stripe/stripe0 ******* parameters extracted from in-core disklabel are: cylinders=3303 heads=255 sectors/track=63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=3303 heads=255 sectors/track=63 (16065 blks/cyl) Do you want to change our idea of what BIOS thinks ? (I have no clue what to answer here, so 'no' is the answer because I couldn't tell you the acceptable values for this if you beat me senseless) Strangely enough the values from previous fdisk runs are still there when I continue... I've 'cleared' the plexes and stripes twice now... And if the partition/slice confusion isn't complete enough, fdisk tells you about partitions when the rest of your life in FreeBSD, you'll call them 'slices'... Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 10474317 (5114 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 651/ head 254/ sector 63 Do you want to change it? [n] I answer 'n' and continue with "partition" 2... The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 10474443, size 42572187 (20787 Meg), flag 0 beg: cyl 652/ head 1/ sector 1; end: cyl 229/ head 254/ sector 63 Do you want to change it? [n] Again, it's the size I want, so 'n' and we move on to "partition" 3 and 4, which I don't use and finally end up with: Partition 1 is marked active Do you want to change the active partition? [n] We haven't changed the partition table yet. This is your last chance. parameters extracted from in-core disklabel are: cylinders=3303 heads=255 sectors/track=63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=3303 heads=255 sectors/track=63 (16065 blks/cyl) Information from DOS bootblock is: 1: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 10474317 (5114 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 651/ head 254/ sector 63 2: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 10474443, size 42572187 (20787 Meg), flag 0 beg: cyl 652/ head 1/ sector 1; end: cyl 229/ head 254/ sector 63 3: 4: Should we write new partition table? [n] Here I answer reasonably 'y' so my math gets written to disk. You'd think that we would have a s0 and s1 (slice 0 and 1) somewhere to be able to continue with the next bunch of monkeys, aka disklabel, aka bsdlabel (yeah sounds like a Bond film here)... but, alas, we have a couple new mysterious devices suddenly: paracles:/stand#> ll /dev/stripe/. total 0 crw-r----- 1 root operator 4, 231 Jan 11 12:50 stripe0 crw-r----- 1 root operator 4, 0x00010002 Jan 4 18:01 stripe0a crw-r----- 1 root operator 4, 0x00010003 Jan 4 18:01 stripe0c with a date from a week ago! Really, the box is sync'd with ntpd... There's probably an explanation somewhere. Now we see what the *label programs say (I know they're the same binary, fwiw) : paracles:/stand#> disklabel /dev/stripe/stripe0 # /dev/stripe/stripe0: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 53067776 16 unused 0 0 c: 53067792 0 unused 0 0 # "raw" part, don't edit I have no stripes to label (partition). Anybody want to tell me what/where I'm doing/going wrong here? I thought the magic of geom was that it was "stackable, cool, ". What magic am I missing? 'gpt' seems to agree with fdisk: paracles:/stand#> gpt show /dev/stripe/stripe0 start size index contents 0 1 MBR 1 62 63 10474317 1 MBR part 165 10474380 63 10474443 42572187 2 MBR part 165 53046630 21162 So what's broken here? I could use a hint or two... -- Yours truly, Shaun D. Jurrens shaun@shamz.net Norway From owner-freebsd-geom@FreeBSD.ORG Tue Jan 11 16:10:42 2005 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91CA516A4CE for ; Tue, 11 Jan 2005 16:10:42 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1402643D1F for ; Tue, 11 Jan 2005 16:10:42 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j0BGDOKe009868; Tue, 11 Jan 2005 08:13:24 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j0BGDOBG009867; Tue, 11 Jan 2005 08:13:24 -0800 Date: Tue, 11 Jan 2005 08:13:24 -0800 From: Brooks Davis To: Shaun Jurrens Message-ID: <20050111161324.GA8528@odin.ac.hmc.edu> References: <20050111110012.GB75478@atreides.freenix.no> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline In-Reply-To: <20050111110012.GB75478@atreides.freenix.no> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: freebsd-geom@freebsd.org Subject: Re: partitioning and labeling geom devices X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 16:10:42 -0000 --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 11, 2005 at 12:00:12PM +0100, Shaun Jurrens wrote: > Now I have /dev/stripe/stripe0 and i want to subdivide this into two slic= es > (aka. DOS partitions) and then partition the slices into various FreeBSD > partitions, (so the a-h thingies, for those catching up). This is sort of > where the concept goes to hell. >=20 > Sysinstall just barfs literally with 'BARF 269' as error code. Being the > lazy sysinstall weenie that I am, this was discouraging. The next step is > to dig into the myriad of similar tools in the post geom FreeBSD world to > see how one can get the job done. 'fdisk' seemed to be a good place to > start, but we also have 'gpt' which almost has a longer BUGS section than > description in the manpage. So we run with fdisk... Ideally you should use gpt, fdisk+bsdlabel are headed the way of to dodo (though they will take a long time to get there). > Do you want to change our idea of what BIOS thinks ? >=20 > (I have no clue what to answer here, so 'no' is the answer because I > couldn't tell you the acceptable values for this if you beat me senseless) You probalby need to answer yes yere. You don't care what the BIOS might think, you care what freebsd thinks. > Strangely enough the values from previous fdisk runs are still there when= I > continue... I've 'cleared' the plexes and stripes twice now... And if the > partition/slice confusion isn't complete enough, fdisk tells you about > partitions when the rest of your life in FreeBSD, you'll call them > 'slices'... >=20 > Warning: BIOS sector numbering starts with sector 1 > Information from DOS bootblock is: > The data for partition 1 is: > sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) > start 63, size 10474317 (5114 Meg), flag 80 (active) > beg: cyl 0/ head 1/ sector 1; > end: cyl 651/ head 254/ sector 63 > Do you want to change it? [n]=20 >=20 > I answer 'n' and continue with "partition" 2... >=20 > The data for partition 2 is: > sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) > start 10474443, size 42572187 (20787 Meg), flag 0 > beg: cyl 652/ head 1/ sector 1; > end: cyl 229/ head 254/ sector 63 > Do you want to change it? [n] >=20 > Again, it's the size I want, so 'n' and we move on to "partition" 3 and 4, > which I don't use and finally end up with:=20 >=20 > Partition 1 is marked active > Do you want to change the active partition? [n]=20 >=20 > We haven't changed the partition table yet. This is your last chance. > parameters extracted from in-core disklabel are: > cylinders=3D3303 heads=3D255 sectors/track=3D63 (16065 blks/cyl) >=20 > Figures below won't work with BIOS for partitions not in cyl 1 > parameters to be used for BIOS calculations are: > cylinders=3D3303 heads=3D255 sectors/track=3D63 (16065 blks/cyl) >=20 > Information from DOS bootblock is: > 1: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) > start 63, size 10474317 (5114 Meg), flag 80 (active) > beg: cyl 0/ head 1/ sector 1; > end: cyl 651/ head 254/ sector 63 > 2: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) > start 10474443, size 42572187 (20787 Meg), flag 0 > beg: cyl 652/ head 1/ sector 1; > end: cyl 229/ head 254/ sector 63 > 3: > 4: > Should we write new partition table? [n]=20 >=20 > Here I answer reasonably 'y' so my math gets written to disk. You'd think > that we would have a s0 and s1 (slice 0 and 1) somewhere to be able to > continue with the next bunch of monkeys, aka disklabel, aka bsdlabel (yeah > sounds like a Bond film here)... but, alas, we have a couple new mysterio= us > devices suddenly: >=20 > paracles:/stand#> ll /dev/stripe/. > total 0 > crw-r----- 1 root operator 4, 231 Jan 11 12:50 stripe0 > crw-r----- 1 root operator 4, 0x00010002 Jan 4 18:01 stripe0a > crw-r----- 1 root operator 4, 0x00010003 Jan 4 18:01 stripe0c >=20 > with a date from a week ago! Really, the box is sync'd with ntpd... There= 's > probably an explanation somewhere. Times in /dev are irrelevent, ignore them. I suspect the problem is that you have an entierly bogus MBR partion table on the disk and now you've modified it, possiably exposing a bogus bsdlabel. Before attempting to label a disk, it's generally best to do something like: dd if=3D/dev/zero of=3D/dev/ count=3D64 That way you've nuked the MBR partition table and any bsdlabel labels in the first slice. You might take a look at the sysutils/diskprep port. It's a config file driven disk labeler. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --M9NhX3UHpAaciwkO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFB4/sjXY6L6fI4GtQRAvh/AJ4346EoTV8n8Mt68rWlI3rwY6JQyQCgqx48 YkKmLLm7zBpJIt/fDl7uBdQ= =HmLA -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO-- From owner-freebsd-geom@FreeBSD.ORG Fri Jan 14 16:52:24 2005 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1887916A4CE for ; Fri, 14 Jan 2005 16:52:24 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA45C43D46 for ; Fri, 14 Jan 2005 16:52:23 +0000 (GMT) (envelope-from bjmccann@gmail.com) Received: by wproxy.gmail.com with SMTP id 68so513834wri for ; Fri, 14 Jan 2005 08:52:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=Wr1Ai7fI4AXyhbmdu/fX8c86OR6JPqXLLr5Ex5ACyej8vtnb+68zsHXnH77rv2VTTBomaiIk0SymbbcaLhzC/4z510/l8ANQv8a4mSX3odF2rdGv8TmXg+xCncgIiaXL6rQA2z1ZH+BCcdn9Ms3YN9qzkVUyRJFYNdIsERP1SOg= Received: by 10.54.32.35 with SMTP id f35mr89300wrf; Fri, 14 Jan 2005 08:52:22 -0800 (PST) Received: by 10.54.33.61 with HTTP; Fri, 14 Jan 2005 08:52:22 -0800 (PST) Message-ID: <2b5f066d05011408521a06e380@mail.gmail.com> Date: Fri, 14 Jan 2005 11:52:22 -0500 From: Brian McCann To: freebsd-geom@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: ggatec/ggated cache or buffer? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Brian McCann List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 16:52:24 -0000 Hi all...I posted this in -stable and wanted to post in here as well to see if anyone else can help me out. I'm playing around with ggatec and ggated, and would like to eventually be able to mirror a partition over the network...but for now I've just exported /dev/da1s1d as RO, created the ggate device on the client as RO, mounted it as RO (and tried using async as well), and when I make change on the server, I NEVER see it on the client without unmounting and remounting the client. What's odd, is say I make file 1 by doing: #echo "foo" > /share/bar Then mounting the client, I see the file. Now I delete the file on the server, I can still cat the file on the client. It's like the client can still read the old superblock or something. It appears that ggatec is caching the superblock or something. Is there a way to NOT get it to do this? It seams that if there isn't, right now ggatec/d would only be useful for sharing file systems that don't change. Any and all information is of course welcome! Thanks, --Brian From owner-freebsd-geom@FreeBSD.ORG Sat Jan 15 21:50:01 2005 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E26616A4CE; Sat, 15 Jan 2005 21:50:01 +0000 (GMT) Received: from ss.eunet.cz (ss.eunet.cz [193.85.228.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id A07D043D1D; Sat, 15 Jan 2005 21:50:00 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from localhost.i.cz (ss.eunet.cz. [193.85.228.13]) by ss.eunet.cz (8.13.1/8.13.1) with ESMTP id j0FLoFCp035898; Sat, 15 Jan 2005 22:50:15 +0100 (CET) (envelope-from mime@traveller.cz) From: Michal Mertl To: freebsd-geom@freebsd.org Content-Type: text/plain Date: Sat, 15 Jan 2005 22:49:55 +0100 Message-Id: <1105825795.8572.3.camel@genius2.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: pjd@freebsd.org Subject: crashdump support in geom_mirror X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2005 21:50:01 -0000 Hello, is anyone working on kernel crash dump support for geom_mirror? How difficult is it going to be? I'm willing to invest some time doing the implementation but I don't know where to start. It seems to me it will be very different than normal crash dumps in controller drivers. Thank you Michal Mertl From owner-freebsd-geom@FreeBSD.ORG Sat Jan 15 21:53:05 2005 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C91516A4CE; Sat, 15 Jan 2005 21:53:05 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6898843D54; Sat, 15 Jan 2005 21:53:04 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j0FLr2cE012217; Sat, 15 Jan 2005 22:53:02 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Michal Mertl From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 15 Jan 2005 22:49:55 +0100." <1105825795.8572.3.camel@genius2.i.cz> Date: Sat, 15 Jan 2005 22:53:02 +0100 Message-ID: <12216.1105825982@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: pjd@freebsd.org cc: freebsd-geom@freebsd.org Subject: Re: crashdump support in geom_mirror X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2005 21:53:05 -0000 In message <1105825795.8572.3.camel@genius2.i.cz>, Michal Mertl writes: >Hello, > >is anyone working on kernel crash dump support for geom_mirror? How >difficult is it going to be? I'm willing to invest some time doing the >implementation but I don't know where to start. It seems to me it will >be very different than normal crash dumps in controller drivers. It is impossible at present and unlikely to ever materialize. GEOM requires context-switches to work. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-geom@FreeBSD.ORG Sat Jan 15 22:31:08 2005 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96DB216A4F6; Sat, 15 Jan 2005 22:31:08 +0000 (GMT) Received: from ss.eunet.cz (ss.eunet.cz [193.85.228.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBF8C43D46; Sat, 15 Jan 2005 22:31:07 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from localhost.i.cz (ss.eunet.cz. [193.85.228.13]) by ss.eunet.cz (8.13.1/8.13.1) with ESMTP id j0FMVNV7041924; Sat, 15 Jan 2005 23:31:23 +0100 (CET) (envelope-from mime@traveller.cz) From: Michal Mertl To: Poul-Henning Kamp In-Reply-To: <12216.1105825982@critter.freebsd.dk> References: <12216.1105825982@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-2 Date: Sat, 15 Jan 2005 23:31:03 +0100 Message-Id: <1105828263.8572.17.camel@genius2.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit cc: pjd@freebsd.org cc: freebsd-geom@freebsd.org Subject: Re: crashdump support in geom_mirror X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2005 22:31:08 -0000 Poul-Henning Kamp píše v so 15. 01. 2005 v 22:53 +0100: > In message <1105825795.8572.3.camel@genius2.i.cz>, Michal Mertl writes: > >Hello, > > > >is anyone working on kernel crash dump support for geom_mirror? How > >difficult is it going to be? I'm willing to invest some time doing the > >implementation but I don't know where to start. It seems to me it will > >be very different than normal crash dumps in controller drivers. > > It is impossible at present and unlikely to ever materialize. GEOM > requires context-switches to work. > Ok, thank you. Other than that - I'd like to say - "Good work, PHK a PJD for GEOM and the mirror class". I don't consider this shortcoming really important anyway. Until PJD started writing his classes I hadn't realized the benefits of GEOM. Have you noticed someone just uses gmirror with ggate in production? Idea which, as I understand it, even PJD didn't have when writing the classes. Simple yet efficient way to set-up the disks for high-availability cluster. I don't know if it is possible but with some more layers of gate and fox you could probably implement even high-available SAN. Michal