On Wed, Aug 05, 2009 at 05:16:10PM +1000, leon zadorin wrote:
> On 8/5/09, leon zadorin <leonleo...@gmail.com> wrote:
> > On 8/5/09, Otto Moerbeek <o...@drijf.net> wrote:
> >> 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).
> >
>
> Ah -- you are 100% correct.
>
> Although different blocksizes et al appear to work fine, the
> re-spoofing clears the BSDFFS detection of filesystem in the spoofed
> disklabel (if one cleans out the 1st blocksize bytes on 'raw' disk and
> then re-svnds the whole lot). Thanks for you help on this.
>
> In such a case, there is just 1 more thing I have spinning in my head
> -- w.r.t. to how likely a 'recovery' would be if the disklabel itself
> was written to disk (ala mr. proper) and then the disk sectors where
> the disklabel resides would be clobbered -- would it not have the same
> effect w.r.t. killing the recovery chances?
>
> In essence, the above test of clobbering some data on raw disk is
> equivalently dramatic regardless of whether disklabel is written or
> not or whether 'c' partition is used for ffs or not...
>
> Consequently, I think, it is not as much about the disklabel info
> being unavailable when using c partition directly (as vnconfig appears
> to imply) -- because it is, indeed, available (other than when
> corrupting raw disk data -- in which case even the valid disklabel
> installation would not help)...
>
> ... but rather it is about *written* disklabel being guaranteed to
> remain intact even if/when 'c' partition is changed on the fly by the
> kernel (e.g. in future system releases which is not in my
> question-scope).
>
> In the examples of *corrupted* superblocks though there appears not to
> be much difference -- i.e. "disk sectors hosting the starting
> superblock being corrupted" vs "disk sectors hosting disklabel being
> corrupted": both are irrecoverable (?)
this is a question about bootstrapping. If the main superblock is
damaged, information in the label is used to find alternate
superblocks. If the label is damaged, yes, you are in deeper trouble,
but:
The big difference is that a disklabel is relatively easy to
recover (the system even makes backups for your automatically). The
label is in a fixed spot, and there is a tool (disklabel(8)) to
rewrite it.
The main thing is: a spoofed label is not very useful if non-default
ffs values are used because the cyl per group, blocksize and fragsize
fields are not recorded. And even if you use an on-disk label, the
values are not maintained for 'c' partitions.
One last note: the code to find alternate superblocks in fsck_ffs
could be improved. Since the ffs2 changes, the layout policy has been
changed (also for ffs1 filesystems). The current code is always able
to find the 1st alternate, but if this once is damaged, it might not
find other alternates in all cases. It's on my to-do list to fix this.
-Otto
