Date: Fri, 29 Jun 2012 10:52:59 +0400 From: "Andrey V. Elsukov" <ae@FreeBSD.org> To: Pawel Jakub Dawidek <pjd@FreeBSD.org>, freebsd-geom@FreeBSD.org, Poul-Henning Kamp <phk@FreeBSD.org> Subject: GEOM metadata manager (was: Re: [CFC/CFT] large changes in the loader(8) code) Message-ID: <4FED50CB.8060104@FreeBSD.org> In-Reply-To: <20120628230725.GB1438@garage.freebsd.pl> References: <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> <4FEB5A3C.5050900@borderworlds.dk> <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> <4FEC22A0.9000109@freebsd.org> <4FEC2D86.2040505@freebsd.org> <8D85513D-CDFC-4D62-AA5A-F82F46E28CE5@xcllnt.net> <20120628214902.00004e34@unknown> <146B8DC1-4B66-4E78-BBB3-3954DC305424@xcllnt.net> <20120628230725.GB1438@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB953E6FB8013A1139DCC8965 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 29.06.2012 3:07, Pawel Jakub Dawidek wrote: >> [...] If the metadata was somewhere >> else, then we wouldn't need to kluge various places to deal with the >> ambiguity and visible interoperability problems of the various tools a= nd >> OSes. [...] >=20 > Where is "somewhere else", exactly? >=20 > If somewhere else on this disk, then where? At the begining of the disk= ? > Then you would complain that it keeps metadata where the primary header= > should be located and also MBR metadata, BSDlabel metadata, etc. > Somewhere in the middle of the disk? Some future GPTng may want to use > the same spot, but also gmirror-unaware boot loader will see corrupted > data (shifted by one sector). Come on... >=20 > If somewhere else is not on this disk, then I'm sorry, but this is > totally impractical. Disks are the place you store stuff. In 99% of the= > cases there is no other place to store it, but the disk itself. Should > we ask users to use additional disk to keep mirror's metadata? I have an idea. A new GEOM class GEOM_MDMGR. It provides new API to write= and read metadata, e.g.: g_read_metadata(...) and g_write_metadata(...) funct= ions. It keeps own data on the specially delegated for this partition. +-------------------------------- | GEOM_MDMGR header +-------------------------------- | GEOM_MDMGR database | the list of entries +-------------------------------- | one sector for each geom +-------------------------------- | .... +-------------------------------- | GEOM_MDMGR header +-------------------------------- Now, we can modify each needed GEOM class and replace some g_write_data/g= _read_data with new functions. How it will work: When GEOM class tastes some provider it calls g_read_metadata(). GEOM_MDM= GR receives request for reading metadata and looks in the database. It analyzes infor= mation that gets from the parameters list. This may be: geom rank, provider size= , block offset, etc. If there is none registered in the database, then GEOM_MDMGR just forward= s this request to the given provider. If there is some metadata registered, then it retu= rns this metadata to the geom. We can keep this database on each device, it can contain information abou= t all geoms, i.e. not only about device where the database is. It can provide to us ne= w abilities, like taste ordering based on the rank... Of course there are some problems that need to ponder. --=20 WBR, Andrey V. Elsukov --------------enigB953E6FB8013A1139DCC8965 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.4.10 (MingW32) iQEcBAEBAgAGBQJP7VDRAAoJEAHF6gQQyKF67vEH/Rq1iQLvMCX5gU622p2Cjs8H DS/4LM0vHiUIGXDljzKge7qGHkodeb/jPoY+aM1R3myimTya92bCNvNSuPNTAanL qLqQHfo7R+FriunvMFsGBAcAXYLntL98vrYGOKrVHT3bGCUmegZ2wtlxmw7oiuLt YpC5CT0pAeahhC59NHUKTMseV/xQxX93LlRjpKtvbjPVM2Kakp8D8E9bjc7XckeK DCQbZja9wcLlqRIqCxqEefA6461roAyeMAHP+jzw/ZomrLA8rv+hRf2WC5mphjmf Zw/0lXo10lUb4iDPoGl5JZ3xe2jqfo1OFferLIC9tz1APvPr2dMQgaXedjzWJLc= =gz+0 -----END PGP SIGNATURE----- --------------enigB953E6FB8013A1139DCC8965--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FED50CB.8060104>