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 (?) leon. >> >> 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.
