On Wed, Aug 05, 2009 at 02:17:14AM +1000, leon zadorin wrote:
> On 8/4/09, Otto Moerbeek <o...@drijf.net> wrote:
> > On Tue, Jul 28, 2009 at 03:26:08PM +1000, leon zadorin wrote:
> >
> >> That's all I am saying. Feel free to ignore or make "blah blah blah"
> >> noises :-)
> >>
> >> So now we can, perhaps, get back (if at all) to the man pages and what
> >> they are implying wrt original question.
> >>
> >> Leon.
> >
>
> Hello Otto,
>
> Firstly I'd like to thank you for replying with actually interesting
> and constructive comments.
>
> Secondly, I hope you don't mind, I'd like to address your post in an
> "out of order" fashion. So... starting from the source-code of the
> fsck_ffs...
>
> >
> > You might want to check the source of fsck_ffs. It contains code to
> > locate alternate superblocks, and that code will not work for the 'c'
> > partition.
> >
>
> I'm starting by looking in setup.c (in sbin/fsck_ffs). Namely the
> implementation of 'calcsb' call, and it appears to work fine even if
> 'c' partition is passed to it, e.g. "/dev/rsvnd3c"
>
> the line
> 'lp = getdisklabel(dev, devfd)'
> produces disklabel fine even if there is no disk-label installed (in
> coherence with man 5 disklabel)...
>
> the line
> 'pp = &lp->d_partitions[*cp - 'a'];'
> evaluates to 2 ('c' - 'a') and indeed the default disklabel has no
> less than value of 3 for 'd_npartitions' so accessing the 3rd array
> element for (c) partition info appears to be ok...
But the next test (pp->p_fstype != FS_BSDFFS) will abort.
>
> the above observations have been tested with a minor program (see
> attachment or at the end of message).
>
> Perhaps, *indeed*, I am not looking in *all* of the right places and
> so in the meantime (as I will be looking more into the rest of the
> fsck_ffs code when I get more time), I thought I'd hack up a quick
> empirical scenario: svnd an image, plonk newfs on c partition then
> clobber the starting 16k and see if fsck firstly detects bad
> superblock and then recovers ok...
>
> ... and the tests appear to indicate that it does actually work.
I don't have time now to test your scenario. But I'm pretty sure your
test will fail the moment non-default fragment or blocksizes are used
in such a way that the first alternate superblock does not end up at
it's usual place. Or maybe another scenario where the first alternate
is corrupted too, who knows? Also, disklabel test should preferable
include reboots to force the on-disk label to be read or spoofed
again.
Showing that a single scenario works for you doesn't show any validity
in the general sense.
Once again: the manual pages give guidance to maximize your chances of
recovering a filesystem in case of damage AND allow the implementation
certain freedom. Not following the advice will put your data at risk
in case of disaster. A new version of OpenBSD might even be that
disaster (for you).
-Otto
