| What does dumpfs -a /dev/rdk0
show?
christos
There is some progress. The trick is the -N flag to newfs, which shows plenty of super-block backups: S# newfs -N -O 2 dk0
/dev/rdk0: 9537535.0MB (19532871680 sectors) block size 16384, fragment size 2048
using 51572 cylinder groups of 184.94MB, 11836 blks, 22976 inodes.
super-block backups (for fsck_ffs -b #) at:
160, 378912, 757664, 1136416, 1515168, 1893920, 2272672, 2651424, 3030176, 3408928, 3787680, 4166432, 4545184, 4923936, 5302688, 5681440, 6060192, 6438944, 6817696, ...
But even here, for each super-block listed, I got this result (of course, the number was 160,378912, etc on the other attempts)
# fsck_ffs -y -b 160 /dev/rdk0 ~
Alternate super block location: 160
** /dev/rdk0
BAD SUPER BLOCK: MAGIC NUMBER WRONG
# fsck_ffs -y -b 160 /dev/dk0 ~~
Alternate super block location: 160
** /dev/rdk0
BAD SUPER BLOCK: MAGIC NUMBER WRONG
#
Feels...hosed
On Mon, Apr 27, 2020 at 12:17 PM Christos Zoulas <christos%astron.com@localhost> wrote:
In article <CAOaX04PBWG4P2cQ31v0gZ7mPZa7bC-jRvC2fusdoJL-WgOFA2g%mail.gmail.com@localhost>,
Michael Cheponis <Michael.Cheponis%gmail.com@localhost> wrote:
>-=-=-=-=-=-
>
>I plugged in a 10TB USB disk, was working fine, then today it got weird.
>
>
>
>*# ls
>/t>▒x4S▒▒XWе▒3▒▒Hj▒▒l▒▒gw▒▒▒▒,▒=▒&▒X▒▒צA▒▒▒B▒w l: Invalid argument*
>
>*# umount -f /t*
>
>
>
>
>
>*# fsck -f -tffs /dev/dk0** /dev/rdk0** File system is already clean** Last
>Mounted on /t** Phase 1 - Check Blocks and Sizestoo many inodes
>18446744073214959280*
>
>Is the data gone that I've been loading onto it for the past several weeks?
Try using an alternative superblock.
christos
<sanitizer.log>
|