Anyone any idea about what I can do about the thousands of DUP msgs I get?Whilst trying to salvage a UFS partition usingfsck -y /dev/da0s3a
I get msgs about EXCESSIVE DUP BLKS.
It's a 250GB partition. Is there any chance of salvaging anything from it?
I wasn't aware of any particular problems with the disk when I last booted from it several months ago.
fsck -y ada0s3a
several times I keep ending up after 20 mins withYOU WILL NEED TO RERUN FSCK.
CYLINDER GROUP ***: INTEGRITY CHECK FAILED
REBUILD CYLINDER GROUP? no
YOU WILL NEED TO RERUN FSCK.
** Phase 1b - Rescan For More DUPS
fsck_ffs: bad inode number 2 to next inode
I got that one, recently. No matter if I say yes or no at that point, fsck will always just coredump.CYLINDER GROUP ***: INTEGRITY CHECK FAILED
REBUILD CYLINDER GROUP? no
I never got a coredump, just a msg saying I would need to rerun FSCK, which I have done many times, with the same result. To my surprise, I found I was able to mount the partition and copy most of the files, so have no idea about the extent of any damage.I got that one, recently. No matter if I say yes or no at that point, fsck will always just coredump.
I zeroed and then tested the entire disk, no issues. Then putting it into service again the same error appeared again. I replaced the disk. The same error appeared again.
But, while it is apparently impossible to fsck and fix such a filesystem, it was always possible to mount it and read the files from it, without errors.
Just to make sure -- you are not running fsck on rw mounted partition?After attempting to RO mount the partition
Well, that`s not much better in the outcome. :/I never got a coredump, just a msg saying I would need to rerun FSCK, which I have done many times, with the same result.
fsck
...I will never know what happened to the file system or why it got so damaged. I have quite a number of laptop disks and this one failed to boot some time ago, so I put it on one side. I'm now trying to catalog these disks and sort out any problems. I understand that UFS is robust and have always been able to recover any corruption in the past, so have never previously delved into what options fsck provides. One thing I can't figure out is how I can I stop getting 'REBUILD CYLINDER GROUP? no'.There are lots of questions you ask, and most of them are not answerable.
What happened to the file system? How did it get so damaged? Usually, UFS is quite tolerant of things like crashes or power failures, so a massive set of errors seems implausible.
The best thing to do you have already done: Run fsck. There are three things left: (a) Read as much as you can, but be aware that files and directories may be corrupted. (b) Find a UFS expert who is willing to spend hours or days hand-fixing your file system, and perhaps retrieve a few more files. (c) Investigate what caused the corruption, and never do it again.
There isHow would a UFS expert go about 'hand fixing' the file system? What tools would he use?
dumpfs
, it shows the data of the cylinder groups. And then there are the header files in /usr/include, and practically the whole filesystem design should be coded there. Is this the issue?PR 255979
This particular disk has 13.0-RELEASE installed.According to that PR it was fixed before 13.1-RELEASE. Surely balanga is running at least that, if not 13.2?
Looking at dumpfs() it mentions:-There isdumpfs
, it shows the data of the cylinder groups. And then there are the header files in /usr/include, and practically the whole filesystem design should be coded there.
And concerning the large picture of the over-all structure and concept, maybe the BSD book tells a bit about that.
Not sure how to interpret this? Does it mean I can rebuild the partition?If -m is specified, a newfs(8) command is printed that can be used to
generate a new file system with equivalent settings. Please note that
newfs(8) options -E, -R, -S, and -T are not handled and -p is not useful
in this case so is omitted. Newfs(8) options -n and -r are neither
checked for nor output but should be. The -r flag is needed if the
filesystem uses gjournal(8).
I don't have advanced knowledge of UFS/FFS. However, concerning the line shown, you'll find at page SMM:3-13 of paper.pdf or 4.3. Phase 1 - Check Blocks and Sizes:When booting from a separate (13.1) system I am able to create a log file to capture the output of fsck, but invariably stops at some point after 15 mins or so.
What I have noticed is sequences of numbers such as
13827(085 - 110) DUP I=690553
ie 16 consecutive addresses have the same DUP. Does I mean inode?hhhhhhhhhhhhhhhhhhhhhh
Not sure what these numbers indicate
B DUP I=I
Inode I contains block number B that is already claimed by another inode. This error condition may invoke
the EXCESSIVE DUP BLKS error condition in Phase 1 if inode I has too many block numbers claimed
by other inodes. This error condition will always invoke Phase 1b and the BAD/DUP error condition in
Phase 2 and Phase 4
cat <logfile> | nc termbin.com 9999