[haiku-bugs] [Haiku] #8041: Heavy filesystem usage produces inodes that checkfs cannot open and cannot fix
- From: "Don Quixote" <trac@xxxxxxxxxxxx>
- Date: Fri, 21 Oct 2011 01:23:35 -0000
#8041: Heavy filesystem usage produces inodes that checkfs cannot open and
cannot
fix
-------------------------------------------------+-------------------------
Reporter: Don Quixote | Owner: axeld
Type: bug | Status: new
Priority: normal | Milestone: R1
Component: File Systems/BFS | Version:
Keywords: checkfs, corruption, inode, | R1/Development
Tracker, copy, Trash, delete, stresstest | Blocked By:
Blocking: | Has a Patch: 0
Platform: x86 |
-------------------------------------------------+-------------------------
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 r42778, 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 r42884 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.
--
Ticket URL: <http://dev.haiku-os.org/ticket/8041>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
