On 8/5/09, Otto Moerbeek <[email protected]> wrote: > 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.
Automatic backup sounds nice. Although I suppose I could use the same principles to 'back up' the actual ffs superblock sectors to a separate file/location/disk (dd if=/dev/rsvnd3c of=some_other_storage bs=1 count=xxx) and during restoration clobber it back onto unused/blank 'c' partition :-) :-) ;-) The main question would be what info is updated to superblock during fs use (the 'clean' / 'last cleaned' flags could be considered insignificant though). Interestingly enough (mostly for my understanding), if we are talking about backing/saving disklabel to a file and why the following practices would not work (for reasons other than 'c' partition interpretation-change): vnconfig svnd3 ./image_file # being a badboy... newfs svnd3c then running disklabel and "saving" to asii file should not be seen as allowing for restoration of 'c' partition (disklabel -R svnd3 ascii_file) with BSDFFS on it -- even after clobber-and-reboot has been applied to disk as per previous experiments... Because (?) this would not work as the *re*writing of disklabel to disk (which had none previously stored on it) would end up stepping on sectors previously used for other things... (if such was decided to be written to the actual image file)... Anyway -- thanks for your info/thoughts on this ! > 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 Interestingly, newfs -b 32786 -f 4096 svnd3c (directly on 'c' partition) survives reboot. That is after reboot disklabel svnd3 shows 'c' partition as BSDFFS with aforementioned (custom?) blocksizes and fragsizes. leon.
