r...@reedmedia.net ("Jeremy C. Reed") writes:
>writing fsbn 288240960 ... bn 288243008
>writing fsbn 544623424 ... bn 544625472
>My system basically hung when I accessed some files. I had to power off
>a few times after I gave up waiting.
There are several layers of retries that makes accessing the damaged
sectors very slow.
Unfortunately that's a write error. A SATA drive that cannot write
a sector cannot re-allocate it either.
>I also tried using badsect with same number. The manual says "sector"
>and the command-line usage says "blkno". It resulted in something like
> block ... in superblock area: cannot attach
Yes. badsect tries to allocate a bad sector so that it isn't used
for data. Doesn't work for meta-data blocks and doesn't work
for already used blocks.
>localhost# /sbin/disklabel sd4
>4 partitions:
># size offset fstype [fsize bsize cpg/sgs]
> a: 1250263728 0 4.2BSD 0 0 0 # (Cyl. 0 -
>1240340)
> d: 1250263728 0 unused 0 0 # (Cyl. 0 -
>1240340)
>disklabel: boot block size 0
>disklabel: super block size 0
That says it is a disk that is used without partitioning, unlikely
to be true for a system disk. I guess 'disklabel -r' will tell that
there is no label on the disk anymore.
>localhost# fsck_ffs -b 32 /dev/sd4a
>Alternate super block location: 32
>** /dev/rsd4a
>BAD SUPER BLOCK: MAGIC NUMBER WRONG
>Running for hours:
>localhost# scan_ffs -b /dev/sd4a
>Disk: 3AS fictitious
>Total sectors on disk: 1250263728
>FFSv2 sb at 191 size 1237910688, last mounted on
>FFSv2 sb at 223 size 1237910688, last mounted on /
>FFSv2 sb at 254 size 203423744, last mounted on
>FFSv2 sb at 318 size 203423744, last mounted on /
>FFSv2 sb at 2176 size 623508480, last mounted on
>FFSv2 sb at 2240 size 623508480, last mounted on /
These might be candidates, but...
>I am guessing following is different blocksize, Or I don't understand
>why doesn't match above.
You have a damaged disklabel. So 'sd4a' is the whole disk and the reported
block numbers of found superblocks are absolute.
Before you can access the filesystem you have to repair the disklabel
(in-core, or use a wedge as a partition).
It's also a different FFS version (scan_ffs found FFSv2, you
checked FFSv1 layout).
My guess would be:
sd0a starts at block 2048, that's a common default nowadays.
FFSv2 sb at 2176 size 623508480, last mounted on
-> superblock at 2176-2048 = relative sector 128
FFSv2 sb at 2240 size 623508480, last mounted on /
-> first backup superblock at 2240-2048 = relative sector 192
This would also fit the layout that
newfs -N -V4 -O2 -s 623508480 -F /dev/null
reports.
>I am currently backing it up with
>localhost# dd if=/dev/rsd4a of=/bigdisk/backup/backup-rsd4a-image bs=32k
>progress=10000
If there is a unreadable block (likely), this will abort. You can use
conv=noerror,sync
to ignore read errors and to replace unreadable data with null bytes.
There is one more problem, dd tries to read 'bs' sized chunks. If any sector
in that chunk is bad, the whole chunk is bad. You either need to use bs=512
(very slow) or try to patch up the sectors in the chunk that are still
readable. In the latter case you can also use bs=1024k for maximum speed.
There is 'dd_rescue' in pkgsrc that should make this simpler, but I haven't
tried it.
