Opened 7 years ago

Closed 7 years ago

#8712 closed bug (duplicate)

filesystem issue

Reported by: jonas.kirilla Owned by: axeld
Priority: normal Milestone: R1
Component: File Systems/BFS Version: R1/Development
Keywords: Cc:
Blocked By: #3150 Blocking:
Has a Patch: no Platform: All

Description

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)

Attachments (3)

syslog.old.txt (512.0 KB) - added by jonas.kirilla 7 years ago.
syslog.txt (92.8 KB) - added by jonas.kirilla 7 years ago.
checkfs.txt (1.1 KB) - added by jonas.kirilla 7 years ago.

Download all attachments as: .zip

Change History (15)

comment:1 Changed 7 years ago by jonas.kirilla

Summary: filesystem vfs issue?filesystem issue

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

comment:2 Changed 7 years ago by bonefish

Component: System/KernelFile Systems/BFS

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?

Changed 7 years ago by jonas.kirilla

Attachment: syslog.old.txt added

Changed 7 years ago by jonas.kirilla

Attachment: syslog.txt added

comment:3 Changed 7 years ago by 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.

comment:4 Changed 7 years ago by X512

Does «checkfs /boot» command fix problem?

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

comment:5 in reply to:  4 ; Changed 7 years ago by 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.

comment:6 in reply to:  5 Changed 7 years ago by 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.

Changed 7 years ago by jonas.kirilla

Attachment: checkfs.txt added

comment:7 Changed 7 years ago by 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?)

comment:8 in reply to:  7 Changed 7 years ago by 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).

comment:9 Changed 7 years ago by 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.

comment:10 in reply to:  9 ; Changed 7 years ago by 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.

comment:11 in reply to:  10 Changed 7 years ago by 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. :)

comment:12 Changed 7 years ago by axeld

Blocked By: 3150 added
Resolution: duplicate
Status: newclosed

So I make this just another dupe of #3150.

Note: See TracTickets for help on using tickets.