Heavy filesystem usage produces inodes that checkfs cannot open and cannot fix

[Don Quixote]

The filesystem in question is a VirtualBox .vdi sparse image. When compressed with xz -9, it shrinks to 323 MB. If someone wants to examine it, let me know how to transfer it to you. I could put it up on my web server and send you a link, but would need to take it down after you get it.

I created two BFS filesystems under hrev42778, one 2.0 GB for /boot and the other 8.0 GB for /Bild. I then thrashed on /Bild repeatedly over a couple of weeks while occasionally checking it with checkfs. This included checking out and building the Haiku sources on it.

Always checkfs said that /Bild was OK, but last night I got a link failure from the keyboard add-on because collect2 said the input_server had an unrecognized file format.

After that checkfs said it could not open perhaps thirty or forty different inodes. Most of them were existing directories but some of them were "entry"'s. Sorry, I don't have the exact error message - once I saw this error, I did not want to touch the filesystem data anymore as forensic analysis may yield some insight.

The kinds of stuff I did was to check out the Haiku sources with Subversion, build them as far as I could get, copy the folder containing the sources and the out-of-tree build folder to a duplicate, then copy again while deleting the first copy in the tracker.

I also did all this while running all the Demos at the same time.

Finally I exercised the kernel a bit with:

$ cd /Bild/Haiku

$ find . -exec grep "Hello, World" {} \; -print

That takes hours and hours to run, as it forks a grep process for each file and subdirectory. (Note that grep -r is much more efficient than using find; I did this on purpose to thrash on the disk.)

From time to time I did an "svn update".

After filing Bug #8038, I installed Nightly Build hrev42884 and created two similar filesystems. (I wanted the bigger /boot filesystem so I could use lots of virtual memory.) This build completed without error and created a raw Haiku image successfully. I have not yet checked whether it will boot.

I've been using VirtualBox OSE under Ubuntu 11.04 on a MacBook Pro (Core Duo, NOT Core 2 Duo, Model Identifier MacBookPro1,1).

All the VMs I've used have connected to their storage with SATA. Do we have problems with SATA that would not exist with IDE?

I have lots of serial port logs if you want them. The one suspicious entry that appears in them is that traversing the Haiku source tree would occasionally produce:

bfs: bfs_open_dir:1616: Not a directory

I have run checkfs right after seeing that, but checkfs did not find any errors. Reading from the directory tree that produced that message did not produce any corruption right away, it was only last night that I got corruption for the first time.

[waddlesplash]

Please retest with a recent nightly.

[X512]

Seems fixed. I build various big projects (Haiku, Blender, Mesa, LLVM etc.) in Haiku without BFS corruptions. BFS corruptions only appear when something special occured (KDL etc.).

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone