documentation of GEOM data structures needed

[Erich Dollansky]

Hi,

On Mon, 11 Nov 2013 16:48:05 +0000
symbolics at gmx.com wrote:

> On Mon, Nov 11, 2013 at 11:50:32PM +0800, Erich Dollansky wrote:
> > 
> > On Mon, 11 Nov 2013 15:11:41 +0000
> > symbolics at gmx.com wrote:
> > 
> > > On Mon, Nov 11, 2013 at 06:32:16PM +0800, Erich Dollansky wrote:
> > > > 
> > > > On Mon, 11 Nov 2013 09:18:36 +0000
> > > > symbolics at gmx.com wrote:
> > > > 
> > > > > On Mon, Nov 11, 2013 at 04:24:00PM +0800, Erich Dollansky
> > > > > wrote:
> > > > > > 
> > > > > > I would need a documentation of the GEOM data structure. A
> > > > > > disk got damages in a strange way during the process of
> > > > > > backing up data. It was partitioned with gpart as all my
> > > > > > disks using the MBR schema. When creating the backup, the
> > > > > > system crashed. The disk was not usable anymore. I found
> > > > > > out that the MBR was overwritten before the backup was
> > > > > > started while the beginning of the first partition seems to
> > > > > > be ok.
> > > > > > 
> > > > > > I hope to be able to recover the data saving me one week of
> > > > > > work.
> > > > > 
> > > > > As I understand things, you believe that your filesystems are
> > > > > okay and you just want to recreate the MBR so you can try to
> > > > > fsck and mount
> > > > 
> > > > this is the basic idea.
> > > > 
> > > > > them? How did you set the disc MBR up in the first place? If
> > > > > you used the automatic scheme in the installer and you know
> > > > > the size of the
> > > > 
> > > > I used the manual way creating 6 partitions.
> > > 
> > > Do you know the sizes and order of how they were set up? They're
> > > all UFS2 or a mixture of other things too?
> > 
> > they are all UFS plus one swap. I have two other which should have
> > the same partitioning with the exception that the size of the disk
> > differ by a few sectors. This should only affect the end of the
> > size of the last partition.
> 
> 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.
> ...
> 
> 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?

> > > > > 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.

Erich