Changeset 25477 in project for release/4/ugarit/trunk/README.txt

11/06/11 10:07:42 (10 years ago)
Alaric Snell-Pym

ugarit: Unit test suite now covers everything except fold-archive-node over directories (but that's really hard to test, and really simple to implement, so not worth testing, right?)

1 edited


  • release/4/ugarit/trunk/README.txt

    r20325 r25477  
    266266## Backends
    268 * Support for remote backends. This will involve splitting the
    269   backends into separate executables, and having the frontend talk to
    270   them via a simple protocol over standard input and output. Then it
    271   will be possible to use ssh to talk to backends on remote machines,
    272   as well as various other interesting integration opportunities.
     268* Eradicate all GPL taint from gdbm by using sqlite for storing
     269  metadata in backends!
     271* Remove backend-log. Have just backend-fs, backend-splitlog, and
     272  maybe a backend-sqlite for everything-in-sqlite storage (plus future
     273  S3/SFTP backends). Not including meta-backends such as backend-cache
     274  and backend-replicated.
     276* Support for recreating the index and tags on a backend-log or
     277  backend-splitlog if they get corrupted, from the headers left in the
     278  log. Do this by extending the backend protocol with a special
     279  "admin" command that allows for arbitrary backend-specific
     280  operations, and write an ugarit-backend-admin CLI tool to administer
     281  backends with it.
     283* Support for unlinking in backend-splitlog, by marking byte ranges as
     284  unused in the metadata (and by touching the headers in the log so we
     285  maintain the invariant that the metadata is a reconstructible cache)
     286  and removing the entries for the unlinked blocks, perhaps provide an
     287  option to attempt to re-use existing holes to put blocks in for
     288  online reuse, and provide an offline compaction operation.
    274290* Support for SFTP as a storage backend. Store one file per block, as
    278294  talk that simple binary protocol. Tada!
    280 * Support for S3 as a storage backend. What's the best way to get at
    281   the S3 API? Write our own client, or find a C library to wrap?
    283 * Support for recreating the index and tags on a backend-log or
    284   backend-splitlog if they get corrupted, from the headers left in the
    285   log.
     296* Support for S3 as a storage backend. There is now an S3 egg!
    287298* Support for replicated archives. This will involve a special storage
    300311  recreated in usage, as otherwise the system may assume blocks are
    301312  present when they are not, and thus fail to upload them when
    302   snapshotting.
     313  snapshotting. The individual physical archives that we put
     314  replication on top of won't be "valid" archives unless they are 100%
     315  replicated, as they'll contain references to blocks that are on
     316  other archives. It might be a good idea to mark them as such with a
     317  special tag to avoid people trying to restore directly from them. A
     318  copy of the replication configuration could be stored under a
     319  special tag to mark this fact, and to enable easy finding of the
     320  proper replicated archive to work from.
    304322## Core
     324* Eradicate all GPL taint from gdbm by using sqlite for storing
     325  the mtime cache!
    306327* Better error handling. Right now we give up if we can't read a file
    379400  referencing the old one as a parent.
     402* Dump/restore format. On a dump, walk an arbitrary subtree of an
     403  archive, serialising objects. Do not put any hashes in the dump
     404  format - dump out entire files, and just identify objects with
     405  sequential numbers when forming the directory / snapshot trees. On a
     406  restore, read the same format and slide it into an archive (creating
     407  any required top-level snapshot objects if the dump doesn't start
     408  from a snapshot) and putting it onto a specified tag. The
     409  intension is that this format can be used to migrate your stuff
     410  between archives, perhaps to change to a better backend.
    381412## Front-end
    383414* Better error messages
    385 * Archive transfer: a command to open two archives. From the source
    386   one, it lists all tags, then for each tag, walks the history, and
    387   for each snapshot, copies it to the destination archive. For
    388   migrating archives to a new backend.
    390416* FUSE support. Mount it as a read-only filesystem :-D Then consider
    392418  copy-on-write of blocks to a buffer area on the local disk, then the
    393419  option to make a snapshot of `current`.
    395 * More explicit support for archival usage: really, a different kind
    396   of tag. Rather than having a chain of snapshots of the same
    397   filesystem, the tag would have some kind of database of snapshots,
    398   with more emphasis on metadata and searchability.
    400421* Filesystem watching. Even with the hash-caching trick, a snapshot
    492513# Version history
     515* 0.8: decoupling backends from the core and into separate binaries,
     516  accessed via standard input and output, so they can be run over SSH
     517  tunnels and other such magic.
    494519* 0.7: file cache support, sorting of directories so they're archived
    495520  in canonical order, autoloading of hash/encryption/compression
Note: See TracChangeset for help on using the changeset viewer.