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)
~>
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.
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.
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