On Thu, 4 Dec 2003 08:24:16 -0800 (PST) "Scott I. Remick" <[EMAIL PROTECTED]> probably wrote:
> > --- Sergey 'DoubleF' Zaharchenko <[EMAIL PROTECTED]> wrote: > > If you want to be more sure, try dd'ing your (suspectedly damaged) > > superblock and some of its (suspectedly OK) copies into different files: > > > > # dd if=/dev/ad6s1e skip=... bs=512 count=16 of=somefile > > > > As /usr/src/sys/ufs/ffs/fs.h suggests, for THE superblock skip should be > > 16 if you have UFS1 or 128 or 512 if you have UFS2 (if my maths is > > correct). These commands shouldn't do anything harmful to /dev/ad6s1e. [snip] > I am suspecting there is something wrong in my syntax for fetching the > superblocks. I see that the SB size is always 8192 bytes regardless so it > should be 512*16 as in the dd command. And I checked that the #s output by > newfs -N were block positions and not raw byte permissions. > > However newfs -N is saying that it is reporting the positions using a > blocksize of 16384. In which case, 160 would mean 160 * 16384 = 2621440 > (byte pos). To translate to the 512-byte blocks, this means the skip should > be 5120 (and 12048384 and 24091648 respectively for the 2nd & 3rd sb > positions). However, when I grab 8192-byte chunks using these skip settings > w/ dd, they don't match up either. I was hoping I was onto something. :( Unless I am very much mistaken, the positions reported by newfs should always be multiplied by the sector size (512), not by the block size. So what you were doing is ok... > Yet you say using the same # output by newfs -N as the skip for dd worked > for you... hmm. This suggests that something else (looking suspiciously at the disklabel) is screwed, not the superblocks... I think we'll end up digging through the hex dump of the beginning of the drive. I've got a (probably bad) idea. If you say that the partition was mounted as /data, then you could do a # hd /dev/ad6s1 |grep /data It should come up soon (the superblock should be close to the beginning of the drive, right?). This way you can at least figure out where your superblock lies (rounding the address of `/data' to 8K). Considering the above discussion, you can calculate the *correct* address of the `e' partition by subtracting 8K or 64K or 256K. See if it matches the one in the disklabel. Of course, this is all possible only if your superblock isn't screwed enough to NOT contain `/data'. This won't find you the copies of the superblock, BTW, as they are not modified my a mount. > _______________________________________________ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- DoubleF Non-Reciprocal Laws of Expectations: Negative expectations yield negative results. Positive expectations yield negative results.
Description: PGP signature