Opened 14 years ago
Closed 8 years ago
#6170 closed bug (invalid)
BFS panic on certain files
Reported by: | Ziusudra | Owned by: | axeld |
---|---|---|---|
Priority: | critical | Milestone: | R1 |
Component: | File Systems/BFS | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
I have certain files that cause BFS to panic when deleting, copying or moving them with Tracker. checkfs and rm also trigger the panic. Continuing 3 times will allow the action to complete and the fs will be readonly.
I can tar the file or copy it to another BFS partition, but it loses whatever causes the panic.
These are object files from building Haiku and Web+, but those are the only cases where I've created a large number of files.
Attachments (4)
Change History (9)
by , 14 years ago
Attachment: | empty-trash-bt.jpg added |
---|
by , 14 years ago
Attachment: | copy-to-bt.jpg added |
---|
by , 14 years ago
Attachment: | checkfs-bt.jpg added |
---|
comment:1 by , 14 years ago
Priority: | normal → critical |
---|
by , 14 years ago
Attachment: | bfsinfo-session.txt added |
---|
comment:2 by , 14 years ago
I just deleted the 3 .o files without error, but the session file will cause a panic. Though in this case it will copy the file without error.
I forgot to mention that when I got an error copying before, if I continued the copy would succeed and the copy of the file would have the same behaviour.
comment:3 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
This should be resolved with Axel's recent BFS changes. checkfs also can repair BTree's now.
If anyone still encounters this issue post hrev43930, please let us know so we can re-open this bug.
comment:4 by , 13 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
comment:5 by , 8 years ago
Resolution: | → invalid |
---|---|
Status: | reopened → closed |
The bfsinfo output looks completely normal, and doesn't hint to any problem. It doesn't seem to be related to the problematic files mentioned before, though. In any case, this ticket does not hold enough information to do anything about it. There might be a chance that the problem has already been fixed in the mean time, too. If something like this occurs again, please report it again, though.
Looks like your directory's B+tree was corrupted. Unfortunately, it's usually hard to know whose fault that is after the fact; you can just see that BFS gracefully handles the case - it just panics because that's what it should do for now ;-)
It would be interesting to see what kind of data made it into the B+tree. You can use 'ls -i' to find out which inode number the parent directory has, and then use bfsinfo part of BFS tools, available on BeBits) to have a look at their contents.
Hopefully, the B+tee is just broken in a harmless way (ie. no foreign data), and that would point to a bug in the B+tree implementation, which would then hopefully be a duplicate or related to bug #6034.