From owner-freebsd-geom@FreeBSD.ORG Tue Nov 12 09:40:55 2013 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 27746C8 for ; Tue, 12 Nov 2013 09:40:55 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C39182D5E for ; Tue, 12 Nov 2013 09:40:54 +0000 (UTC) Received: from lemon ([80.7.17.14]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LqQTl-1VAwFf48R7-00e1EI for ; Tue, 12 Nov 2013 10:40:51 +0100 Received: by lemon (Postfix, from userid 1001) id 6EC10EB300; Tue, 12 Nov 2013 09:40:50 +0000 (GMT) Date: Tue, 12 Nov 2013 09:40:50 +0000 From: symbolics@gmx.com To: freebsd-geom@freebsd.org Subject: Re: documentation of GEOM data structures needed Message-ID: <20131112094050.GA1808@lemon> References: <20131111162400.0bc7dfef@X220.ovitrap.com> <20131111091836.GA83261@lemon> <20131111183216.5ec80e9e@X220.ovitrap.com> <20131111151141.GA1381@lemon> <20131111235032.6a6f26f7@X220.ovitrap.com> <20131111164805.GB1381@lemon> <20131112111658.4cb1ef95@X220.ovitrap.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131112111658.4cb1ef95@X220.ovitrap.com> X-Provags-ID: V03:K0:EWvMhK1PZ2aDNn8tCcWKgTWWt7HorKlc5E0qEp5MG31iL1ExG9w gb8isSQW4Y1fUE67qzUvL8R5Z6a/NUC3SgWRszeWR2Y5fxeGxFBcws4FxaeaZTDBd8mwesV HhgCRyAwUJzNsb+YKa4hmmkqJ45IkZM1K8VsocKGsc7nE+K9g2OE/oo9TkiXkqm6Cbp7N22 1ziMviFHeSY+yJIvXWXQg== X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 09:40:55 -0000 On Tue, Nov 12, 2013 at 11:16:58AM +0800, Erich Dollansky wrote: > Hi, > [...] > > > > In which case run `gpart backup da1' (assuming da1 is the name of one > > of the intact discs). You can store the output text to a file and > > then edit it to fit. Then use `gpart restore da0' to apply it to the > > new disc. > > > > First of all, take backups of your existing MBRs, just in case: > > > I copied already the identified data structures into files. > > > # gpart backup da1 > ~/da1.gpart > > This is what I would like to avoid. I would like to understand how it > works and do it manually. The code is in sys/geom and sbin/geom. The structure definitions can be found in the header files in sys/geom. The backup command itself can be found in sbin/geom/class/part/geom_part.c. > > > > If you like you can try to fit the first five partitions first and > > then worry about the last one later. If da1 is an intact disc then > > running the following piped command should reset all but the last > > partiton on da0: > > > > # gpart backup da1 | sed \$d | gpart restore da0 > > > > Try fscking and mounting the first five partitions and see how you get > > on. Hopefully they'll just work. > > > The hopefully is the point why I would like to do it by hand. I do not > think that there is a huge secret behind. It is just that I did not > find the documentation. Or doesn't it exist? It depends on what you mean by documentation I suppose. Quite a lot of the GEOM API is documented to varying levels (something I intend to improve as my time allows). You can look at the sys/sys/diskmbr.h header file for some useful information though. The MBR format is documented on Wikipedia. > > > > > > disc, you could reconstruct things that way. What does `gpart > > > > > > show' look like at the moment? > > > > > > > > > > It does not come that far > > > > > > > > > > gpart list da0 > > > > > gpart: No such geom: da0. > > > > > > > > > > is all I get. > > > > > > > > > > My luck is that I have three disks which are the type but > > > > > manufactured with some months between. But their sizes differ a > > > > > bit. I think that I should be able to recover much by just > > > > > comparing the entries. > > > > > > > > > > > > > You can try looking at diskinfo -v da0 to see the numbers. > > > > > > > 512 # sectorsize > > > 500107860480 # mediasize in bytes (466G) > > > 976773165 # mediasize in sectors > > > 0 # stripesize > > > 0 # stripeoffset > > > 60801 # Cylinders according to firmware. > > > 255 # Heads according to firmware. > > > 63 # Sectors according to firmware. > > > 0000000000006121 # Disk ident. > > > > > > One other disk shows the same data while the third one shows this: > > > > > > 512 # sectorsize > > > 500107862016 # mediasize in bytes (466G) > > > 976773168 # mediasize in sectors > > > 4096 # stripesize > > > 0 # stripeoffset > > > 15504336 # Cylinders according to firmware. > > > 1 # Heads according to firmware. > > > 63 # Sectors according to firmware. > > > TF0504YS02ZPBP # Disk ident. > > > > > > > These look really different. Are you using other GEOM classes? What > > else is different about these discs? > > The media size is already different. The drives are all Hitachi's with > 4k sectors. They should be all from the same factory but obviously > there is a difference. > Ok, good luck. --sym