Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 26 Feb 2004 21:38:07 +0100
From:      Pawel Jakub Dawidek <pjd@FreeBSD.org>
To:        Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc:        freebsd-geom@freebsd.org
Subject:   Re: GEOM stripe library.
Message-ID:  <20040226203807.GD5720@darkness.comp.waw.pl>
In-Reply-To: <886.1077788852@critter.freebsd.dk>
References:  <20040225103057.GB5506@darkness.comp.waw.pl> <886.1077788852@critter.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help

--gneEPciiIl/aKvOT
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 26, 2004 at 10:47:32AM +0100, Poul-Henning Kamp wrote:
+> > * This disk have two slice:
+> > *
+> > * d_slices[0].s_offset =3D3D 1024
+> > * d_slices[0].s_length =3D3D 2048
+> > * d_slices[0].s_virt_offset =3D3D 0
+> > * d_slices[0].s_virt_end =3D3D 2048	(s_virt_offset + s_length)
+>=20
+> I can't really see what we need s_virt_end for.  If you need it for
+> implementation, then please calculate it as part of setup so that
+> the users of this library will not even see it.

All structures are private for library.
Library's user is not aware of structure g_stripe_slice nor g_stripe_group,
he operates on well-known GEOM structures: g_provider, g_geom.

For slices definitions he use g_stripe_add_slice() function and he don't
touch geom_stripe_lib's structures at all. Defining slices for disks is
one-way operation, so this design should be enough and it is also simple.

Look at geom_raid0 implementaion. It only operates on generic GEOM
structures.

+> >/*
+> > * Structure g_stripe_group describes group of disks that are used
+> > * on given offset. This allows to create stripe on disks with different
+> > * sizes.
+> > *
+> > *      disk 0     disk 1     disk 2   START_DISK START_OFFSET
+> > *     +-------+  +-------+  +-------+ 0          0
+> > *     |0000000|  |0000000|  |0000000|
+> > *     |0000000|  |0000000|  |0000000|
+> > *     + - - - +  +-------+  + - - - + 1024       0 + 1024 * 3 =3D3D 30=
72
+> > *     |1111111|             |1111111|
+> > *     |1111111|             |1111111|
+> > *     |1111111|             |1111111|
+> > *     +-------+             + - - - + 2560       3072 + 1536 * 2 =3D3D=
 6144
+> > *                           |2222222|
+> > *                           +-------+ 3072       6144 + 512 * 1 =3D3D =
6656
+> > *
+> > * sc_groups[0].g_ndisks =3D3D 3
+> > * sc_groups[0].g_disks =3D3D { 0, 1, 2 }
+> > * sc_groups[0].g_start_offset =3D3D 0
+> > * sc_groups[0].g_end_offset =3D3D 3072
+> > * sc_groups[0].g_start_disk =3D3D 0
+>=20
+> Where is the actual stripe-width ?  Shouldn't that be a parameter here ?

This structure is also private. Stripe size is defined while one is
calling g_stripe_create() function.
"Groups" are calculated automatically, when all disks are ready.

+> > * sc_groups[1].g_start_disk =3D3D 2560
+>=20
+> s/2560/1024/ ?
[...]
+> > * sc_groups[2].g_start_disk =3D3D 3072
+>=20
+> s/3072/2560/ ?

Right, sorry for mistake.

+> I have been thinking a bit more about this, and I can see a number of
+> in-use striping geometries you cannot handle with this, in particular
+> non-uniform striping (64k from disk0, 128k from disk1, 64k from disk0,
+> 128k from disk1, ...)  There are also some underspecified parameters
+> and some overspecified ones.

Yes, this is not possible, but I'm also not aware of software that is
doing this. I don't think even veritas gives such possibility.
I think this will only complicate calculations.

+> And would look like this in C code:
+>=20
+> 	struct stripe *sp;
+>=20
+> 	sp =3D g_stripe_new(/* consumers */ 3, /* parts */ 3);
+>=20
+> 	sp->consumer[0] =3D c0;
+> 	sp->consumer[1] =3D c1;
+> 	sp->consumer[2] =3D c2;
+> 	sp->slicepart[0].stripes =3D 1024;
+> 	for (i =3D 0; i < 3; i++) {
+> 		sp->slicepart[0].components[i].offset =3D 1024;
+> 		sp->slicepart[0].components[i].bite =3D 1024;
+> 	}
+> 	sp->slicepart[1].stripes =3D 3072;
+> 	sp->slicepart[1].components[0].offset =3D -1; /* autocalculate */
+> 	sp->slicepart[1].components[0].bite =3D 512;
+> 	sp->slicepart[1].components[2].offset =3D -1; /* autocalculate */
+> 	sp->slicepart[1].components[2].bite =3D 512;
+>=20
+> 	sp->slicepart[1].stripes =3D 256;
+> 	sp->slicepart[1].components[2].offset =3D -1; /* autocalculate */
+> 	sp->slicepart[1].components[2].bite =3D 2048;
+>=20
+> 	error =3D g_stripe_calculate(sp);
+>=20
+> Setting offset to -1 means "continue wherever we got to".

I'm not sure how to comments this, because I think you misunderstand
my model.

Here is an example (without errors checking) how to create stripe
using 3 disks: da0, da1, da2. Stripe size is 64kB, metadata are stored
on last disk's sector.

gp =3D g_stripe_create(mp, "test.stripe", /* ndisks */ 3,
    /* stripesize */ 65536, /* sectorsize */ 512, NULL, orphan_func);

pp =3D g_provider_by_name("da0");
error =3D g_stripe_attach(gp, pp, /* disk no */ 0, /* number of slices */ 1=
);
g_stripe_add_slice(gp, pp, /* offset */ 0,
    /* size */ pp->mediasize - pp->sectorsize);

pp =3D g_provider_by_name("da1");
error =3D g_stripe_attach(gp, pp, /* disk no */ 1, /* number of slices */ 1=
);
g_stripe_add_slice(gp, pp, /* offset */ 0,
    /* size */ pp->mediasize - pp->sectorsize);

pp =3D g_provider_by_name("da2");
error =3D g_stripe_attach(gp, pp, /* disk no */ 2, /* number of slices */ 1=
);
g_stripe_add_slice(gp, pp, /* offset */ 0,
    /* size */ pp->mediasize - pp->sectorsize);

That's all, the whole rest will be calculated and configured
automatically.

--=20
Pawel Jakub Dawidek                       http://www.FreeBSD.org
pjd@FreeBSD.org                           http://garage.freebsd.pl
FreeBSD committer                         Am I Evil? Yes, I Am!

--gneEPciiIl/aKvOT
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)

iD8DBQFAPlkvForvXbEpPzQRAo10AKDjmlq589InyUrLHBVtLO9A3r+b5ACg7aVM
doAGTyFia1wt+/9Lt8ntAXs=
=GNeo
-----END PGP SIGNATURE-----

--gneEPciiIl/aKvOT--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040226203807.GD5720>