filesystem issue

[jonas.kirilla]

Installing WebPositive failed on a few files from the libxml packaged named SAX.h and SAX2.h (iirc) with an error message along the lines of "error: cannot create /some/path/..."

Installing mercurial (via installoptionalpackage) failed

Extracting python-2.6.7-x86-gcc2-2011-06-24.zip ...
error:  cannot create /boot/common/lib/python2.6/StringIO.py
error:  cannot create /boot/common/lib/python2.6/StringIO.pyc
error:  cannot create /boot/common/lib/python2.6/StringIO.pyo

Some manual testing in Terminal:

~> touch S
touch: cannot touch `S': General system error
~> touch Sasdf
~> touch St
~> touch Str
touch: cannot touch `Str': General system error
~> touch Stre
touch: cannot touch `Stre': General system error
~> touch Streert
touch: cannot touch `Streert': General system error
~> touch Streertasdfasdf
touch: cannot touch `Streertasdfasdf': General system error
~> touch SA
touch: cannot touch `SA': General system error
~> touch sax
~> touch SAX
touch: cannot touch `SAX': General system error
~> 

mkdir fails in the same way.

hrev44301, gcc2 nightly, raw, and the filesystem was formatted prior to install, from Haiku on another HD partition, perhaps 3-4 months old. SSD drive with no known issues. (OCZ Vertex 2)

[jonas.kirilla]

Having rebooted to another Haiku and mounted the problematic filesystem where the issue appeared, creating files with an initial capital S still fails, so I assume it's an issue within the on-disk filesystem - the state it is in. (Rather than an issue with the vfs or some in-memory representation of on-disk structures.)

[bonefish]

Yeah, the VFS is a rather unlikely candidate for the problem. It really doesn't care what names you pass in, since it only passes them through to the file system. Anything in the syslog?

[jonas.kirilla]

Syslog attached.

I used a Fedora livecd to run an extended check (for s.m.a.r.t. devices) on the disk without finding anything. It's reported as healthy.

[X512]

Does «checkfs /boot» command fix problem?

Warning! Save averything and run «sync» command before to pervent data loss.

[axeld]

Replying to X512:

Warning! Save averything and run «sync» command before to pervent data loss.

Huh? checkfs uses transactions like the rest of BFS. You just cannot save anything while checkfs runs, as it blocks all other file system writes.

Anyway, this sounds like a B+tree corruption. If the above happens in all directories, it's likely that the name B+tree is corrupted. If detected, this is something that checkfs can indeed repair. If it cannot find a problem, would it be possible to get the output of a bfsinfo run for that index?

If it only happens in certain folders, checkfs cannot fix the issue, though, and won't detect anything.

[X512]

Replying to axeld:

Huh? checkfs uses transactions like the rest of BFS. You just cannot save anything while checkfs runs, as it blocks all other file system writes.

I mean save anything and sync caches before running checkfs. checkfs cause KDL sometimes. Mayble checkfs bug is fixed, I haven't seen it for a long time.

[jonas.kirilla]

Running checkfs solved it.

Looks like checkfs says the b+trees of the name and size attribute indexes(?) were broken somehow. (Are these specialcased and treated differently?)

[axeld]

Replying to jonas.kirilla:

Running checkfs solved it.

Looks like checkfs says the b+trees of the name and size attribute indexes(?) were broken somehow. (Are these specialcased and treated differently?)

What do you mean by that?

The index B+trees can be repaired by checkfs, as it can iterate over all files using the file system hierarchy. While it's possible to recreate other B+trees as well, it's a lot more work to implement (and eventually more time intensive as well).

[jonas.kirilla]

Oh nothing much. I was thinking that since something went wrong in my filesystem related to the indexing of name and size, perhaps there's some code related to these that differs from (other?) code related to general indexing of attributes. (Two sets of routines to work on the same/similar datastructures, the b+trees, and mismatching in some detail.) Perhaps there is no relevancy to this line of thought and no bug to uncover.

[anevilyak]

Replying to jonas.kirilla:

Oh nothing much. I was thinking that since something went wrong in my filesystem related to the indexing of name and size, perhaps there's some code related to these that differs from (other?) code related to general indexing of attributes.

The only real distinction between indices and directories is that the index B+ trees have to allow duplicates. Otherwise they're pretty much treated the same as far as the FS code is concerned. What does make those two special (along with iirc last_modified) is that they by definition touch every single file in the disk and consequently see far more activity than any other B+ tree in the filesystem. Thus, any bugs are statistically most likely to manifest there.

[jonas.kirilla]

Replying to anevilyak:

What does make those two special (along with iirc last_modified) is that they by definition touch every single file in the disk and consequently see far more activity than any other B+ tree in the filesystem. Thus, any bugs are statistically most likely to manifest there.

Good point. :)

[axeld]

So I make this just another dupe of #3150.