On 8/5/09, Otto Moerbeek <o...@drijf.net> wrote:
> 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.
Not at all. Of course, I was *not* expecting to see FFS on 'c'
partition without first plonking newfs on it. Besides the attached
code (c++) includes this test and it is not tripped by this condition
(so yeah -- if I had simply 'vnconfig svnd3 ./image' then, naturally,
no FFS on it; but the test/questions obviously were related to putting
an fs on 'c' partition ('newfs svnd3c') vs the "writing disklabel and
newfs on 'a'" for example).
>>
>> 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.
Ok sweet -- thanks for this. I'll try these cases as well (w/o
non-default settings -- as I'd replied to an earlier email, I don't
consider such to be within the context of the discussion).
>
> Showing that a single scenario works for you doesn't show any validity
> in the general sense.
>
I wasn't trying to show validity of the general sense here. I was
trying to show invalidity of categorical statements made in vnconfig
man page... but I will test with a reboot as well...
> in case of disaster. A new version of OpenBSD might even be that
> disaster (for you).
Once again -- forward-compatibilty is not my requirement (a new
version may have lots of different non backwards-compatible changes,
who knows?)
Leon.
