From owner-freebsd-geom@FreeBSD.ORG Fri Jun 29 06:53:21 2012 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 883E81065670; Fri, 29 Jun 2012 06:53:21 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from mail.kirov.so-ups.ru (ns.kirov.so-ups.ru [178.74.170.1]) by mx1.freebsd.org (Postfix) with ESMTP id E74B18FC1B; Fri, 29 Jun 2012 06:53:17 +0000 (UTC) Received: from kas30pipe.localhost (localhost.kirov.so-ups.ru [127.0.0.1]) by mail.kirov.so-ups.ru (Postfix) with SMTP id 9D818B8027; Fri, 29 Jun 2012 10:53:06 +0400 (MSK) Received: from kirov.so-ups.ru (unknown [172.21.81.1]) by mail.kirov.so-ups.ru (Postfix) with ESMTP id 19105B8026; Fri, 29 Jun 2012 10:53:06 +0400 (MSK) Received: by ns.kirov.so-ups.ru (Postfix, from userid 1010) id 11B55BA06D; Fri, 29 Jun 2012 10:53:06 +0400 (MSK) Received: from [127.0.0.1] (unknown [10.118.3.52]) by ns.kirov.so-ups.ru (Postfix) with ESMTP id CE906BA03F; Fri, 29 Jun 2012 10:53:05 +0400 (MSK) Message-ID: <4FED50CB.8060104@FreeBSD.org> Date: Fri, 29 Jun 2012 10:52:59 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Pawel Jakub Dawidek , freebsd-geom@FreeBSD.org, Poul-Henning Kamp 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> In-Reply-To: <20120628230725.GB1438@garage.freebsd.pl> X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB953E6FB8013A1139DCC8965" X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release X-SpamTest-Info: Not protected Cc: Subject: GEOM metadata manager (was: Re: [CFC/CFT] large changes in the loader(8) code) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 06:53:21 -0000 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--