Ticket #3150 (new bug)

Opened 16 months ago

Last modified 6 months ago

BFS directory corruption.

Reported by: bga Owned by: axeld
Priority: blocker Milestone: R1
Component: File Systems/BFS Version: R1/pre-alpha1
Keywords: Cc: olive@…, alaricx@…, miqlas@…, rossi@…, HubertNG@…
Blocked By: Platform: x86
Blocking: #3932, #4011

Description

I set up a new partition to run Haiku and did a clean install of r28657. Setting it up included downloading sources for stuff I am working on, configuring/dowmnloading emails, setting backgrounds, etc.

This morning I turned my computer on and booted to this partition. I was decided to get ArmyKnife to compile under Haiku and switched to its directory. Doing "ls" on it resulted into this:

~/development> cd armyknife/
~/development/armyknife> ls
ls: reading directory .: Bad data
Makefile  Makefile_armyknife  Makefile_armyknife_tte  Makefile_libsanta

syslog showed this:

KERN: B+tree header size 6132779464041449732 doesn't fit file size 2048!
KERN: bfs: SetTo:471: Bad data
KERN: bfs: KERN: inode tree at block 2624136 corrupt!
KERN: bfs: InitCheck:432: Bad data

This is the disk, just in case:

~/development> df           
Mount           Type      Total     Free     Flags   Device
--------------- -------- --------- --------- ------- --------------------------
/boot           bfs          77.0G     66.6G QAM-P-W /dev/disk/scsi/0/2/0/2

I decided to run checkfs on it although I imagined it would not handle this kind of problem:

~/development> checkfs /dev/disk/scsi/0/2/0/2
prop-base (inode = 4719490), could not be opened
lock (inode = 3148138), has blocks already set, names don't match
documentation (inode = 2624136), could not be opened
checked 115255 nodes, 0 blocks not allocated, 2 blocks already set, 3943 blocks could be freed
        files           92648
        directories     22225
        attributes      268
        attr. dirs      84
        indices         30

Then trying to run ls on the dir again (note no files are showing now. That's because I tried to remove the directory but it failed with directory not empty and removed the files inside it that were ok but not the corrupt ones):

~/development/armyknife> ls
ls: reading directory .: Bad data

Ans syslog still showed the same error:

KERN: B+tree header size 6132779464041449732 doesn't fit file size 2048!
KERN: bfs: SetTo:471: Bad data
KERN: bfs: inode tree at block 2624136 corrupt!
KERN: bfs: InitCheck:432: Bad data

Attachments

syslog Download (487.9 KB) - added by rossi 11 months ago.
rossi's syslog

Change History

  Changed 16 months ago by karmak

  • cc olive@… added

  Changed 16 months ago by axeld

Can you do a "ls -i" to see the inode number of that directory? The "blocks already set" problem can only show the second (or third, ...) claimer of the block.

  Changed 16 months ago by bga

Not much luck with that:

/Haiku1/home/development> ls -i armyknife 
ls: reading directory armyknife: Bad data
/Haiku1/home/development/armyknife> ls -i
ls: reading directory .: Bad data

  Changed 16 months ago by dustin howett

Try straight "ls -i" in /Haiku1/home/development.

  Changed 16 months ago by dustin howett

  • cc alaricx@… added

follow-up: ↓ 7   Changed 16 months ago by Adek336

This also happened to me, I reinitialized the partition, and after about 30 minutes later it happened again. Interestingly, after a reboot I can't find the offending file like if the problem disappeared.

in reply to: ↑ 6   Changed 16 months ago by axeld

Replying to Adek336:

This also happened to me, I reinitialized the partition, and after about 30 minutes later it happened again. Interestingly, after a reboot I can't find the offending file like if the problem disappeared.

It would be interesting to know what you did in those 30 minutes :-) Did you initialiaze the partition inside Haiku, and just continued working, or was it the boot partition? Also, how much memory do you have, and how large is the partition?

I suspect this to be a problem of the block cache - maybe it reverts some blocks for whatever reason with old contents.

It would be nice to have a reproducible test case, though, as I haven't been able to reproduce this problem yet.

follow-up: ↓ 11   Changed 16 months ago by Adek336

It's not the boot partition, it's 10gb, I've got 3gb RAM. After initially having an error with the partition, I copied some files from it to boot partition, reinitialized, copied the files back from the boot partition. Then, I checked out the Haiku sources and I think I compiled them and then I was changing config files and recompiling, or doing svn stats or diffs or something. And svn, or jam, but rather svn reported errors on some directory with "test" in the name. I rebooted and it works well since then.

  Changed 16 months ago by anevilyak

Just a minor observation here, BGA also has large amounts of RAM (I want to say roundabouts 4GB), and is also seeing issues...perhaps the large mem amount has something to do with it?

  Changed 16 months ago by bga

Actually it is 3 Gb too. I have 4 Gb total but 1 Gb is being mapped by my 2 512 Mb video cards so only 3 Gb are actually seen by Haiku.

in reply to: ↑ 8   Changed 16 months ago by axeld

  • summary changed from OpenBFS directory corruption. to BFS directory corruption.

Replying to Adek336:

And svn, or jam, but rather svn reported errors on some directory with "test" in the name. I rebooted and it works well since then.

Did you reboot hard, that is without syncing the caches (ie. "reboot" in KDL, or via the reset button)?

Also, you can check if you have the same problem as bga by running "checkfs" on the disk; if BFS does not report blocks that are already set, it's not the same problem.

  Changed 16 months ago by Adek336

I don't remember how I rebooted, but indeed, checkfs doesn't report blocks already set.

  Changed 14 months ago by bbjimmy

I had this issue once while installing from an image file to a partition in QEMU and loosing power. Two files were damaged. The fix for me was running forcerm from my Zeta install to remove the offending files and re-installing haiku from the image file. Maybe we need a forcerm tool for haiku?

  Changed 12 months ago by miqlas

  • cc miqlas@… added

I have the same problem:

~/Desktop/Trash/wine-1.1.17> ls
ls: reading directory .: Bad data

in the syslog:

KERN: bfs: bfs_create_index:1980: File or Directory already exists
Last message repeated 2 times
KERN: bfs: InitCheck:310: Bad data
KERN: bfs: inode at 1572989 is already deleted!
KERN: bfs: GetNextMatching:1060: Bad data
KERN: bfs: could not get inode 1572989 in index "be:deskbar_item_status"!
KERN: bfs: InitCheck:310: Bad data
KERN: bfs: inode at 1593323 is already deleted!
KERN: bfs: GetNextMatching:1060: Bad data
KERN: bfs: could not get inode 1593323 in index "be:deskbar_item_status"!
KERN: bfs: InitCheck:310: Bad data
KERN: bfs: inode at 1593331 is already deleted!
KERN: bfs: GetNextMatching:1060: Bad data
KERN: bfs: could not get inode 1593331 in index "be:deskbar_item_status"!
KERN: register_domain(9, unix)
KERN: B+tree header size 5917768436999877237 doesn't fit file size 2048!
KERN: bfs: SetTo:471: Bad data
KERN: bfs: inode tree at block 2632493 corrupt!
KERN: bfs: InitCheck:441: Bad data
KERN: B+tree header size 5917768436999877237 doesn't fit file size 2048!
KERN: bfs: SetTo:471: Bad data
KERN: bfs: KERN: inode tree at block 2632493 corrupt!
KERN: bfs: InitCheck:441: Bad data
KERN: B+tree header size 5917768436999877237 doesn't fit file size 2048!
KERN: bfs: SetTo:471: Bad data
KERN: bfs: inode tree at block 2632493 corrupt!
KERN: bfs: InitCheck:441: Bad data

The "df" command:

~/Desktop/Trash/wine-1.1.17> df 
Mount           Type      Total     Free     Flags   Device
--------------- -------- --------- --------- ------- --------------------------
/boot           bfs           7.0G    760.2M QAM-P-W /dev/disk/ata/1/master/1_1

The checkfs give error massage:

~/Desktop/Trash/wine-1.1.17> checkfs /dev/disk/ata/1/master/1_1
checkfs: Could not prepare the device for modifications: Invalid Argument

  Changed 11 months ago by rossi

  • cc rossi@… added

I have a similar problem and I'm not sure whether they are related or not. If I should file a seperate ticket, please let me now.

Here the "storyline":

rossi@wayreth haiku> cd ../buildtools/ rossi@wayreth buildtools> svn up svn: Expected 'legacy/gcc/libf2c/libF77' to be a directory but found a file rossi@wayreth buildtools> svn cleanup rossi@wayreth buildtools> svn up svn: Directory 'legacy/gcc/libf2c/libF77/.svn' containing working copy admin area is missing rossi@wayreth buildtools> cd .. rossi@wayreth haiku> rm -rf buildtools/ rm: FATAL: directory `buildtools//legacy/gcc/libf2c' changed dev/ino rossi@wayreth haiku>

Which prompted me to run "checkfs":

rossi@wayreth home> checkfs /boot/ tmp (inode = 5243643), has blocks already set text-base (inode = 5770269), has blocks already set props (inode = 5770277), has blocks already set prop-base (inode = 5770270), has blocks already set tmp (inode = 5243641), has blocks already set input_server (inode = 2099298), could not be opened checked 171980 nodes, 0 blocks not allocated, 165 blocks already set, 87 blocks could be freed

files 144153 directories 27192 attributes 382 attr. dirs 228 indices 25

Also attached the syslog in case its needed.

Changed 11 months ago by rossi

rossi's syslog

  Changed 10 months ago by Hubert

  • cc HubertNG@… added

  Changed 8 months ago by axeld

  • blocking 3932 added

(In #3932) As this info is not really helpful, I'll just regard it as a duplicate of #3150.

  Changed 8 months ago by axeld

  • blocking 4011 added

(In #4011) You obviously managed to corrupt your BFS disk (ie. you ran into some Haiku bug). Since this ticket does not contain any helpful information that distinct it from other tickets, I'll close it as a duplicate of #3150.

Please note that the "checkfs" utility should now be able to solve these problems (since r31775).

  Changed 6 months ago by mmlr

  • milestone changed from R1/alpha1 to R1

I haven't seen these directory corruptions lately. The causes might have been fixed by now. In any case since these seem to be at least rare by now and checkfs can correct most of the damage, I'm removing it as an alpha blocker.

Note: See TracTickets for help on using tickets.