BFS: Checkfs unable to repair "names don't match"

[kallisti5]

Seeing this one on my long-running Haiku desktop system. 886GB partition.

Haiku catsmeow 1 hrev51062 Apr 3 2017 00:53:58 x86_64 x86_64 Haiku

~> checkfs /Builds/
.PackageManager.h.swp (inode = 9057097), has blocks already set, names don't match
.SoftwareUpdaterWindow.cpp.swp (inode = 9057957), some blocks weren't allocated
        2719468 nodes checked,
        26 blocks not allocated,
        3 blocks already set,
        0 blocks could be freed

        files           2559336
        directories     160000
        attributes      54
        attr. dirs      36
        indices         42

        direct block runs               2731991 (44.50 GiB)
        indirect block runs             6306 (in 538 array blocks, 4.31 GiB)
        double indirect block runs      14144 (in 26 array blocks, 55.25 MiB)
~> checkfs /Builds/
d097b7adcb4daff6d202b7a07d091bdbb962b2 (inode = 9057097), names don't match
.PackageManager.h.swp (inode = 9057097), has blocks already set, names don't match
        2719468 nodes checked,
        0 blocks not allocated,
        3 blocks already set,
        0 blocks could be freed

        files           2559336
        directories     160000
        attributes      54
        attr. dirs      36
        indices         42

        direct block runs               2731991 (44.50 GiB)
        indirect block runs             6306 (in 538 array blocks, 4.31 GiB)
        double indirect block runs      14144 (in 26 array blocks, 55.25 MiB)

This seems like a non-critical issue that checkfs can't solve. Interesting how the error changed on the second run.

[kallisti5]

syslog during checkfs

[axeld]

First of all "has blocks already set" is a critical error that cannot be fixed by BFS without deleting one of the affected files (all of which might be corrupted).

You can use the bfs_tools to find out which nodes are affected (ie. which share the same block(s)).

The "names don't match" error is actually something BFS tries to fix. However, it always propagates the directory name down to the node. So if it's wrong in more than one directory (for example, the name index), it might play ping pong, which also explains why the error message changes. That's the first time this has been reported, though, so you can consider yourself lucky :-)

[kallisti5]

Heh. So by non-critical I mean the rest of the filesystem is ok. Would it make sense for checkfs to ask the user to clear those files to reclaim space?

[axeld]

BFS only knows about the second and all following files. It should probably just give a bit more help in the output. Suggestions welcome :-)