"Cannot find file system superblock" error - how to recover?

[Sergey 'DoubleF' Zaharchenko]

On Tue, 6 Jan 2004 19:43:44 +1030
Malcolm Kay <malcolm.kay at internode.on.net> probably wrote:

> On Tue, 6 Jan 2004 15:05, Sergey 'DoubleF' Zaharchenko wrote:
> > On Tue, 6 Jan 2004 13:29:26 +1030
> >
> > Malcolm Kay <malcolm.kay at internode.on.net> probably wrote:
> > > On Tue, 6 Jan 2004 10:59, Scott I. Remick wrote:
> > > > Sorry for the delay... holidays had me busy.
> >
> > Me too:)
> >
> > > > Hopefully you're still around
> > > > and interested in picking up where we left off. I think we're
> > > > definitely onto something...
> > >
> > > Looking back over some of your e-mails I find:
> > > QUOTE
> > > su-2.05b# disklabel -r /dev/ad6s1c
> > > # /dev/ad6s1c:
> > > 8 partitions:
> > > #        size   offset    fstype   [fsize bsize bps/cpg]
> > >   c: 156344517       63    unused        0     0         # "raw" part,
> > > don't edit
> > >   e: 156344517       63    4.2BSD     2048 16384    89
> > > partition c: partition extends past end of unit
> > > disklabel: partition c doesn't start at 0!
> > > disklabel: An incorrect partition c may cause problems for standard
> > > system utilities
> > > partition e: partition extends past end of unit
> > >
> > > That doesn't look good.
> > > ENDQUOTE
> > >
> > > The 63 offset is spurious. I've seen this before somewhere but can't
> > > remember the details -- i.e the value 63.
> >
> > I know where you've seen this. The normal offset for the first *slice*
> > is 63 sectors, for some historical reasons (those extra sectors were to
> > be used for bad block replacement or something like that).
> >
> 
> Yes, I expect it in the output from fdisk.
> Ignoring for the moment that the BIOS ideas of geometry has nothing 
> to do with the physical reality; all slices start at sector 1 of a track so having
> used sector 1 of the first track (cylinder 0 head 0) for the MBR, the first slice
> must start at cylinder 0 head 1 sector 1; usually an offset of 63 with the assumed
> virtual geometry.
> (Nothing to do with bad block replacement which on modern drives is almost 
> completely hidden)

Yes I know, I meant used to be used for:)

> But I have seen the 63 before in corrupted disklabels, not just slice positions.

Maybe in dedicated disklabels? How did they get *that* corrupted?

> > Not sure how the 63 made it into the disklabel, though.
> 
> Neither do I.
> 
> Malcolm Kay
> 
> 


-- 
DoubleF
You look like a million dollars.  All green and wrinkled.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20040106/db47793d/attachment.bin