History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: COR-1281
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Blocker Blocker
Assignee: Unassigned
Reporter: Amphibian Toad@amphibian.dyndns.org
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
db4o Core

Running out of disk space causes unrecoverable data corruption

Created: 19/May/08 08:23 AM   Updated: 17/Jul/08 04:01 PM
Component/s: None
Affects Version/s: 6.4.32
Fix Version/s: 7.3.45

Time Tracking:
Original Estimate: Not Specified
Remaining Estimate: 0h
Time Spent - 31.67h
Time Spent: 31.67h
Time Spent - 31.67h

Environment: Linux (debian etch). Using the 1.4 jar.

Peers: Carl Rosenberger
Order: 1
Iteration: 45
Original IDS Estimate: 4
Resolution Date: 02/Jun/08 09:53 AM
First Response Date: 27/May/08 01:49 PM
Labels:
Participants: Amphibian Toad@amphibian.dyndns.org, Carl Rosenberger and Patrick Roemer
Number of Attachments: 0
Number of Comments: 3


 Description  « Hide
Testing db4o in bsh, with a view to using it in Freenet. We create a database, and write to it, and restart, it works. Then we deliberately fill up the disk (in another shell), and try to write to the database. db4o throws an Db4oIOException caused by out of disk space, but when we restart it, even if we remove the bigfile occupying all the disk space, we get an IncompatibleFileFormatException.

I have personally tried this with 6.4, a coworker tried it with 7.3, same result except different exception (IncompatibleFileFormat or InvalidSlot).

I know this is a case of deliberately breaking it to see if it still works ... but it ought to work, an embedded database included with an end-user application will frequently run up against temporary out of disk space conditions, it should recover gracefully (as Perst does for example).

 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Patrick Roemer - 27/May/08 01:49 PM
The problem could be reproduced on a "real" limited space hard drive, but we don't have a reliable unit test for it, yet.

The culprit in this case seems to be the CachedIoAdapter which is enabled by default - perhaps this decision should be reconsidered. As a workaround for the time being, explicitly running without the CachedIoAdapter should recover gracefully with all the data stored up to the last commit.

config.io(new RandomAccessFileAdapter()); // no CachedIoAdapter

While looking into it, we also have found some minor issues with graceful recovery from I/O failures, like not releasing the file lock unconditionally. Fixes will be checked in.

Great work... the fix will eventually be backported to 7.2? And somewhere in the distant future, 7.2 will be declared stable, and 6.4 will be deprecated?

Carl Rosenberger - 03/Jun/08 09:18 AM
The fix is backported to the 7.2 and 6.4 branches. The release policy has not been decided upon. Eventually a 7.x build will be declared stable but it is not yet certain that this will be 7.2.