headers
Pawel Jakub Dawidek | 5 Jan 2005 14:48
Picon
Favicon

Re: gmirror confusion

On Sun, Dec 12, 2004 at 04:50:12PM -0700, Ken Gunderson wrote:
+> I'll be lame and follow up my own post...  First, sorry that I confused 
+> "provider" with "consumer", so that question is moot.  However, I note 
+> the following:
+> 
+> >>>>>>>
+> build# bsdlabel mirror/mirror0s1
+> # /dev/mirror/mirror0s1:
+> 8 partitions:
+> #        size   offset    fstype   [fsize bsize bps/cpg]
+>   a:   524288        0    4.2BSD     2048 16384 32776
+>   b:  4194304   524288      swap
+>   c: 78156162        0    unused        0     0         # "raw" part, 
+> don't edit
+>   d:  1048576  4718592    4.2BSD     2048 16384     8
+>   e:  1048576  5767168    4.2BSD     2048 16384     8
+>   f:  8388608  6815744    4.2BSD     2048 16384 28552
+>   g: 16777216 15204352    4.2BSD     2048 16384 28552
+>   h: 46174594 31981568    4.2BSD     2048 16384 28552
+> 
+> build# bsdlabel /dev/mirror/mirror0s1
+> # /dev/mirror/mirror0s1:
+> 8 partitions:
+> #        size   offset    fstype   [fsize bsize bps/cpg]
+>   a:   524288       63    4.2BSD     2048 16384 32776
+>   b:  4194304   524351      swap
+>   c: 78156162       63    unused        0     0         # "raw" part, 
+> don't edit
+>   d:  1048576  4718655    4.2BSD     2048 16384     8
+>   e:  1048576  5767231    4.2BSD     2048 16384     8
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ralf S. Engelschall | 10 Jan 2005 17:36
Picon
Favicon

[HOWTO] FreeBSD system disk mirroring with GEOM

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 <at> FreeBSD.org                        Ralf S. Engelschall
FreeBSD.org/~rse                       rse <at> engelschall.com
FreeBSD committer                      www.engelschall.com
Permalink | Reply | 4 comments |
headers
Adrian Wontroba | 11 Jan 2005 01:42
Picon

Re: [HOWTO] FreeBSD system disk mirroring with GEOM

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
Permalink | Reply | 1 comment |
headers
Ken Gunderson | 11 Jan 2005 02:04

Re: [HOWTO] FreeBSD system disk mirroring with GEOM

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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Shaun Jurrens | 11 Jan 2005 12:00

partitioning and labeling geom devices

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
(Continue reading)

Permalink | Reply | 11 comments |
headers
Brooks Davis | 11 Jan 2005 17:13

Re: partitioning and labeling geom devices

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 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...

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 ?
> 
> (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'...
>
(Continue reading)

Permalink | Reply | 10 comments |
headers
Brian McCann | 14 Jan 2005 17:52
Picon

ggatec/ggated cache or buffer?

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
Permalink | Reply | 1 comment |
headers
Michal Mertl | 15 Jan 2005 22:49
Picon

crashdump support in geom_mirror

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
Permalink | Reply | 2 comments |
headers
Poul-Henning Kamp | 15 Jan 2005 22:53
Picon
Favicon

Re: crashdump support in geom_mirror

In message <1105825795.8572.3.camel <at> 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 <at> 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.
Permalink | Reply | 1 comment |
headers
Michal Mertl | 15 Jan 2005 23:31
Picon

Re: crashdump support in geom_mirror

Poul-Henning Kamp píše v so 15. 01. 2005 v 22:53 +0100:
> In message <1105825795.8572.3.camel <at> 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
Permalink | Reply | 0 comments |

Gmane