well not quite an atomic write, but as close as one can get with java io. Batch writes are serialised and followed by an fsync, so the fsfreeze will either block the next write or the next fsync. Either way is fine from a consistency point of view. The index is checkpointed to the journal periodically, so recovery of the index will at worst be from the last know good state.
look at processQueue in the source http://svn.apache.org/viewvc/activemq/trunk/kahadb/src/main/java/org/apache/kahadb/journal/DataFileAppender.java?view=markup On 2 June 2011 00:19, Steve Smith <tarkast...@gmail.com> wrote: > On 1 June 2011 19:50, Gary Tully <gary.tu...@gmail.com> wrote: >> yes, a restored backup would be recoverable. >> >> In creating a backup, there may be an issue with the lock file, or >> with an inuse journal file. The lock file is not important but you >> would want the latest journal files. >> >> Linux will allow you to freeze a filesystem, I guess other os's have >> similar support. >> http://rwmj.wordpress.com/2010/06/09/freezing-filesystems/ >> >> We may want to introduce a way to have activemq freeze the journal, >> block reads/writes and release open journal and index files for OS's >> that don't have freeze support. > > Thanks Gary. > > Based on what you said I'm not sure that fsfreeze will guarantee a > consistent journal by itself unless the journal is updated in a single > atomic write. Is this the case? > > A user-space KahaDB snapshotting tool would certainly be useful regardless. > > Cheers, > Steve > -- http://fusesource.com http://blog.garytully.com
