Checkfs output

Software
#1

As this is one of the very first time I’m using checkfs (haiku is running on bare metal), I cannot say whether this output is OK.
What does the message “names don’t match” mean?
Should I ignore it? Or: how does a clean checkfs look like?


Welcome to the Haiku shell.

~> uname -a
Haiku shredder 1 hrev56578+70 Feb 22 2023 07:26: x86_64 x86_64 Haiku
~> checkfs /dev/disk/scsi/0/0/0/7
xz_utils-5.2.5-2-x86_64.hpkg (inode = 2666563), names don't match
writable-files (inode = 2637526), names don't match
state_2023-01-14_15:20:10 (inode = 2666516), has blocks already set
activated-packages (inode = 2666525), has blocks already set
        34454 nodes checked,
        0 blocks not allocated,
        7 blocks already set,
        0 blocks could be freed

        files           25324
        directories     8833
        attributes      153
        attr. dirs      98
        indices         46

        direct block runs               34086 (2.74 GiB)
        indirect block runs             611 (in 7 array blocks, 326.94 MiB)
        double indirect block runs      0 (in 0 array blocks, 0 byte)
~>
Building (a minimal) Haiku
#2

It means the name stored in the file and the name stored in the parent directory don’t match. This is not normal.

On a normal run there would be no errors before the “xxx nodes checked” message.

If you run it a second time and the errors are not there anymore, it means that checkfs could fix it on its own. Otherwise, you can try to delete and recreate the affected files.

#3

No, checkfs couldn’t fix the issue, in fact I managed to remove the affected file using rm:

screenshot1
screenshot1864×544 94.1 KB

which, in turn, caused some more packages to be removed.
After this, a different package showed the same error:


Welcome to the Haiku shell.

~> checkfs /dev/disk/scsi/0/0/0/7
zip-3.0-4-x86_64.hpkg (inode = 1573895), names don't match
writable-files (inode = 2637526), names don't match
state_2023-01-14_15:20:10 (inode = 2666516), has blocks already set
activated-packages (inode = 2666525), has blocks already set
        34455 nodes checked,
        0 blocks not allocated,
        7 blocks already set,
        108 blocks could be freed

        files           25324
        directories     8834
        attributes      153
        attr. dirs      98
        indices         46

        direct block runs               34088 (2.74 GiB)
        indirect block runs             612 (in 7 array blocks, 326.94 MiB)
        double indirect block runs      0 (in 0 array blocks, 0 byte)
~>
#4

Maybe it’s time to backup your data and do a clean install before it gets out of control, then

#5

The real problem is “has blocks already set”. This means that two different files claim the same space on disk (only one of them is shown in the output, as it’s not known anymore which file occupied the blocks already).

So if you delete the affected files, it still means that likely two other files are corrupted, too. In any case, after deleting those files, you’ll need to run checkfs again to reclaim the freed space before another file has the chance to claim it. That’s also why checkfs won’t fix those errors: it means that files have been corrupted in a way that cannot be fixed.

There is a tool as part of the bfs-tools (bfswhich, I don’t think that this is part of a standard Haiku install) that you can use to find out which files occupy the same block. The syslog should also contain extra information about the actual blocks that showed the problem. That’s how you can know what files are affected. Given the ‘names don’t match’ error, it might also be a directory stream that is affected.

3 Likes
#6

Thank you for your hint to bfswhich!
it pointed out two files using the same block, then I removed both (one was a ‘state’ subdir under /boot/system/packages/administrative ) and now the output by checkfs is clean at all!

My two cent: after reading Recovering BeFS partition (which was hugely helpful) I agree that BFS Tools deserve their own hpkg

3 Likes