checkfs: "BEOS:LOCALE_LANGUAGE" is always corrupted

[Giova84]

Two days ago i have updated Haiku to hrev 44361. After install and restoring my folders i have run checkfs /boot. Since hrev44361, every time that i run chekfs, i always got:

Ϟ 02:00:49 Ϟ ~ checkfs /boot
BEOS:LOCALE_LANGUAGE (inode = 4701), invalid b+tree
name (inode = 4569), invalid b+tree
Recreating broken index b+trees...
        39869 nodes checked,
        0 blocks not allocated,
        0 blocks already set,
        0 blocks could be freed

And when i try to see if is really fixed, i still obtain the same message.

[axeld]

Can you please add a syslog that contains the output of such a checkfs run? It contains information about what is wrong in particular.

[Giova84]

I have run a checkfs at startup and then grabbed this syslog. At the end of file i read "KERN: bfs: bfs_stat_index:2117: No such file or directory" is related to issue?

[axeld]

I actually don't know, but I wouldn't think so unless checkfs returns an error.

In any case, the "duplicate" lines are the ones that cause the FS to see a need in rebuilding the indexes. It's very strange that it would recreate the same problem, though. How large is that disk? Does it contain personal data? Would it be possible to put it online somewhere so that I could have a look at what's happening?

[Giova84]

I have investigated for two hours and now i have found the reason of issues! First of all i have downloaded and burned the new hrev44384 nightly.

I have booted the live cd; initialized again my disk (as usual) and run a checkfs: no errors found. After this i have run installer on my disk (partition) BFS - 14.65 GiB. After installation i have run again checkfs /mydisk: Again errors about BEOS:LOCALE_LANGUAGE and "name"!!

On my disk i have deleted 1 folder at once from / and every time i have run checkfs. After deletion of the /system folder on root, errors on file system are gone away.. In final i have found that the guilty of errors on filesystem was the folder "locale" located in /boot/system/data.. Ok.. At this point i don't know what is happened, but after three times i have reinstalled again Haiku on my disk (and every time deleting locale" folder), at the end after run a checkfs i no longer got errors! But that's not all! After restoring my personal data i have found that /apps folder was causing again filesystem errors.. After another detailed inspection i have found that the folder "locale" located in /boot/apps/vlc-0.8.6i was causing error about "name".

Now i have deleted vlc and i no longer get any errors on filesystem. I have zipped /boot/system/data/locale and /boot/apps/vlc-0.8.6i/locale

​http://depositfiles.com/files/ihkvs9ql8 ​http://depositfiles.com/files/i1syazru7

[ahenriksson]

Oops, my bad... At least the problem doesn't seem to be dangerous, sorry to waste your time though.

[axeld]

Great, thanks Andreas! I've applied your original patch, and didn't spot anything wrong either, so I'm as guilty as you are. Anyway, I'm going to apply your final patch now.

[axeld]

I haven't yet found the time to actually apply it, but I have some second thoughts, too, maybe you can shed some light on it, because I frankly don't remember:

• Why is it okay for fragment arrays to contain only a single value?
• When checking the minimum array size for duplicate arrays, do we take into account that only the first node must have more than one entry? For subsequent duplicate nodes, it's quite okay to only have a single value. Furthermore, even the first node might only have a single entry as long as it still have children.

Am I missing something here or am I on the right track?

[ahenriksson]

It's the other way around. Like you say, a single entry in a duplicate array is no problem. I don't really know the "high level" reason for why a single entry in a fragment array is disallowed, but since removing it breaks the tree, I've deducted that the existence of it is an error.

[axeld]

Thanks for being so diplomatic about my stupidity :-)

I misread the diff. There is no real problem of having a single entry in a fragment, it's just not necessary to allow this; it just wastes space, as a single entry is not a duplicate anymore, and can just be put into the tree like any other values. While there is no problem reading such trees, the code shouldn't produce them.

I'll go apply your patch in the next few days, thanks for the heads up!

[axeld]

Applied in hrev44480, thanks Andreas!