Slices + stripes and mirrors

[Pawel Jakub Dawidek]

On Fri, May 19, 2006 at 01:06:04PM -0500, Rick C. Petty wrote:
+> On Fri, May 19, 2006 at 01:21:49PM -0400, James Snow wrote:
+> > On Wed, May 17, 2006 at 07:19:55PM +0200, Pawel Jakub Dawidek wrote:
+> > > On Tue, May 16, 2006 at 03:55:07PM -0700, Darcy Buskermolen wrote:
+> > > +> 
+> > > +> I have a 6.1 setup with 4 identical 300GB disks, ad4,6,8,10.  I'd like to 
+> > > +> create a bootable mirror (gm0s1) of all 4 disks on a 512MB slice, and have 
+> > > +> the remaining space a big slice (gs0s2). 
+> > 
+> > I'm going something almost identical and have been having some
+> > difficulty.  
+> 
+> Who don't people use gvinum more?  These more complex setups require more
+> flexibility.  Also gvinum will let you grab the full disks and not deal
+> with mirroring the slices individually.  Using gmirror on slices seems
+> pretty hackish to me.

Maybe for you. This what GEOM infrastucture gives you - you don't care
if this is a disk, slice, partition, mirror device, encrypted device,
etc. It is provider and you can do whatever you need to do with it.
This is the flexibility.

Imagine a configuration where you have 5 disks. Create one 2GB slice on
all disks, and use the rest space for the second slice.
Now, create root file system by mirroring da0s1a and da1s1a.
Create /usr/ on raid3(da2s1, da3s1, da4s1) and create /home/ on
raid3(da0s2, da1s2, da2s2, da3s2, da4s2).
This is the flexibility.

+> > > Ok, first initialize your disks and create two slices on them:
+> > > 
+> > > 	# apply "fdisk -Bi /dev/ad%1" 4 6 8 10
+> > > 
+> > > (If they are identical, you can probably initizlize one of them and copy
+> > >  first 63 sectors to the others.)
+> > > 
+> > > Once you have your slices, create a mirror:
+> > 
+> > I've been using Ralf's guide[1] for the basics of this, and he mentions
+> > that you need to shrink the slice by one sector.  Is this still the case
+> > in 6.1?  If so, when doing two slices per disk, do you need to shrink
+> > both slices by one sector, or only the last slice on the disk?
+> 
+> The reason you nede to shrink the slice is because the metadata for gmirror
+> is stored on the last sector of the provider (which in this case is a
+> slice, but usually is just the disk).  Because the metadata is stored for
+> each instance in the mirror, every slice you mirror will shrink by one
+> sector.  Because you are mirroring slices not disks, gmirror doesn't "know"
+> about the disks.  Again, this method seems very hackish.  If you mirror the
+> entire disk, gmirror will provide a device that is one sector smaller than
+> the disk..  this should be transparent.  If you're not mirroring the entire
+> disk, I think you're halfway down a dangerous path.

Hehe, cool. So check by yourself how gvinum is transparent:)
It doesn't use metadata?:) I'm sure it takes much more than one sector.
And again. You simply don't understand what for GEOM was actually
introduced...

+> In any case, I've had better luck using gvinum even for just plain
+> mirroring.  Also, I feel that his guide implies setting up mirroring is
+> less than trivial.  IMO, it's easier to use a livecd since you have to
+> reboot the box anyway.  For that number of steps, why not use gvinum
+> instead?  You'd have more flexibility and you can do things like resize
+> volumes and add/remove drives while the system is up.

You can't add/remove gmirror's component which the system is up?
Resizing should be done with another GEOM class.

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd at FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20060520/c52a54a2/attachment.pgp