[Zope-Annce] Announcement; DirectoryStorage

Toby Dickenson tdickenson@geminidataloggers.com
Fri, 24 May 2002 17:24:54 +0100

Announcing the first release in nearly two years of
DirectoryStorage - a ZODB storage which keeps its data in a directory 
containing many files; one file per revision per object.

Current status: pre-alpha. I am not yet using this in production.

This is the first release made by myself, based on the work started by
Petru Paler

Available from CVS from http://sourceforge.net/projects/dirstorage


* A ZODB Storage which uses one file per revision of an object.

* A very simple file format. Your data is not locked away inside
  an unfamiliar, opaque database.

* Use familiar filesystem tools for maintaining the database.
  For example:
  * Take an incremental backup using tar.
  * Make crucial persistent objects immutable using file permissions
  * Replication using rsync

* Support for filesystems which are most efficient with many
  files in one directory (such as reiserfs), and also for filesystems
  which are not.

* Support for filesystems with posix semantics. Support for win32
  semantics requires a volunteer.

* Robust transactions, using a journal.

* Full.py: A storage which supports undo (but not versions, yet).
  It needs occasional packing to remove unreachable objects and old
  revisions of reachable objects (like FileStorage)

* Minimal.py: A storage which does not support undo. Packing is needed
  to reclaim the space used by deleted objects. (packing not yet

* Constant memory usage, even during packing. With the right fileystem
  I believe this makes DirectoryStorage the most scalable Storage
  available today.

* Snapshot mode. After entering snapshot mode, the main database
  directory is a self-consistent, up to date, read-only snapshot of
  the storage state. Zope does not lose read/write access to the
  Storage; writes are spooled in a secondary directory. This is ideal
  for taking a backup of the database state without shutting
  down Zope.

* Good redundancy of data. All object state (optionally) carries an md5
  checksum. A storage checking tool is planned