From owner-freebsd-current@FreeBSD.ORG Thu Oct 6 13:43:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFF81106564A for ; Thu, 6 Oct 2011 13:43:49 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 45A778FC15 for ; Thu, 6 Oct 2011 13:43:49 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RBoEl-0000P5-A3 for freebsd-current@freebsd.org; Thu, 06 Oct 2011 15:43:47 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 06 Oct 2011 15:43:47 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 06 Oct 2011 15:43:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Thu, 06 Oct 2011 15:43:30 +0200 Lines: 125 Message-ID: References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> <4E8C6E85.90005@quip.cz> <4E8CD662.90202@quip.cz> <4E8DA627.60003@quip.cz> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAC39782E3DC540A268BC10AD" X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111004 Thunderbird/7.0.1 In-Reply-To: <4E8DA627.60003@quip.cz> X-Enigmail-Version: 1.1.2 Cc: freebsd-geom@freebsd.org Subject: Re: RFC: Project geom-events X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 13:43:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAC39782E3DC540A268BC10AD Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > I am not a GEOM expert, but isn't it wrong concept, that glabel writes > its metadata and publish original device size?=20 It does not. # diskinfo -v /dev/md0 /dev/md0 512 # sectorsize 104857600 # mediasize in bytes (100M) 204800 # mediasize in sectors 0 # stripesize 0 # stripeoffset # glabel create /dev/label/blah md0 # diskinfo -v /dev/label/blah /dev/label/blah 512 # sectorsize 104857088 # mediasize in bytes (100M) 204799 # mediasize in sectors 0 # stripesize 0 # stripeoffset (i.e. one sector is used for glabel). # gpart create -s GPT /dev/label/blah # gpart add -t freebsd -l gptpart label/blah # diskinfo -v /dev/label/blahs1 /dev/label/blahs1 512 # sectorsize 104822784 # mediasize in bytes (100M) 204732 # mediasize in sectors 0 # stripesize 17408 # stripeoffset 710 # Cylinders according to firmware. 32 # Heads according to firmware. 9 # Sectors according to firmware. (i.e. 67 sectors are used for: protective MBR (1), GPT header (1), GPT table (32), the backup GPT header (1) and the backup GPT table (32)). > If some GEOM write > metadata at last sector (or first), then it should shrink the published= > size (or offset).=20 It does that. > Or is the problem at geom_part, that it is writing > metadata past the advertised end of the device? There is no "problem" as far as I can see. The only possible problem is that you are trying to do something outside the specification. This is not the fault of FreeBSD, GEOM, or glabel, and it's even probably not the fault of the specification as it cannot avoid real-world problems such as this. See this: http://www.uefi.org/specs/ If the primary GPT is invalid, the backup GPT is used instead and it is located on the last logical block on the disk. If the backup GPT is valid it must be used to restore the primary GPT. If the primary GPT is valid and the backup GPT is invalid software must restore the backup GPT. If both the primary and backup GPTs are corrupted this block device is defined as not having a valid GUID Partition Header. Even though the primary GPT header contains the LBA of the backup GPT header, this paragraph says that it must be the last sector of the device= =2E > e.g. If I have disk device with size of 100 sectors and glabel metadata= > is stored at the last sector, then glabel should shrink the advertised > size to 99 sectors - then GPT secondary table will be at sector 99 > instead of 100. Maybe an illustration will help. In the scenario like the above, this is what you have on the drive: [ PMBR | GPT 1 | --- random file system data --- | GPT 2 | glabel ] The $glabeled_size is $device_sectors - 1. The size of the GPT "available space" is $glabeled_size - 67. Since the PMBR and primary GPT headers are located at the start of the drive, they are detected there. A tool which is made to the specification from the paragraph above will detect that the second GPT table (GPT 2) is invalid in this configuration and will try to "fix" it by destroying the glabel metadata. It doesn't matter that from GEOM's point of view, the layering is correct and the provider sizes are calculated correctly. If you want to do this, you must do it with something which isn't GPT. --------------enigAC39782E3DC540A268BC10AD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6NsIIACgkQldnAQVacBciy8gCgneDU0rzZPlZ1eV3tFTgPN/Mh qKAAoJHTzpQ/c8ZDstsqN3XJ683agCY+ =Ysg8 -----END PGP SIGNATURE----- --------------enigAC39782E3DC540A268BC10AD--