Add the --rebuild-statcache option.

Add an option which forces cumulus to re-read all files, even if they seem
not to have changed.

This has two main purposes: first, it helps to rebuild the contents of the
statcache from data actually on disk, and as such is useful for adding
object size annotations to files which haven't changed (ordinarily, the
straight re-use of data from the statcache prevents this).

Second, it can be used to detect some simple forms of data corruption; if a
file has not changed (according to stat information) but the checksum
doesn't match the old value in the statcache file, a warning is printed.

Better cope with null values in the segments_used table.

Treat nulls utilization values as 0.0 for cleaning purposes.  These
shouldn't come up, but may have been generated due to bugs in the SQLite
library, so deal gracefully with them instead of failing with an exception.

Make use of size assertions in references where possible.

When writing out a reference to what is known to be a complete object, use
the size-assertion form of a reference.

Eliminate a gcc warning.

Add parentheses around arithmetic near a shift operator, to get rid of a
gcc warning.  The code was correct before, and this change causes it to
diverge from the LBFS sources it was derived from, but it is worthwhile to
get rid of the gcc warning.

Extend object reference syntax with size assertions.

Object references can now include a size assertion, such as [=1024]
which indicates that the referenced object is exactly 1024 bytes in
length.  If a metadata log or statcache file is produced using this
reference form where appropriate, then it should be possible to rebuild
much of the object index in the local database (by looking for files
which are unchanged and computing hashes of blocks from that file where
it is known that an entire object was used, not just a fragment of an
object).

This commit merely adds support for parsing the new references; they are
not yet generated by any code.

Add some missing #include statements.

Some standard include files (stdlib.h and string.h) were not being included
where necessary.  This worked in the past, but seems to break for some
versions of the compiler/standard library, so be sure to include what we
need.

README corrections.

Document the "-v/--verbose" option.

NEWS updates for v0.7 release.

Add a verbose option to cumulus.

By default, do not output a listing of all files as they are backed up.  If
--verbose or -v is specified, then do so.

README updates: explain restores in more detail.

Compute checksum of checksums file while it still exists.

When data is being stored remotely, the checksums file (containing hashes
for all the segments needed by a snapshot) may only be stored locally for a
short period of time.  We can't wait to compute its checksum (for inclusion
into the root descriptor) until the time when the root descriptor is
writtenout, since the checksum file may be gone by then.

Compute the checksum earlier (before sending the checksums file to remote
storage), and save the checksum value until it is written out later.

Fix an example command in the README.

Updates to documentation and contributed scripts for name change.

Do not store subfile signatures for very short blocks.

Don't bother to store subfile signatures for very short files, since it is
probably not worth the effort: we're probably best off just storing a new
copy of the data if it changes anyway.

For now, we used a fixed and non-scientific threshold of 16 kB as the
minimum size before we'll save subfile signatures.  However, short blocks
that are created to store any new chunks needed for a subfile incremental
are always indexed (since we are likely to want to use the same chunks
again in the next backup).

.gitignore update.

Update name of lbs-util program.

Change name of project to Cumulus.

Start changing some references to the LBS name to Cumulus instead.  So far,
changes are in a few of the more user-visible places (name of the
executable, name in the version string).  Many internal references are not
changed, and likely will not be changed immediately (since some of the
changes would change format compatibility).

Hypens are allowed as key names in RFC822-style data.

Update the parsers for the RFC822-style key-value lists.  Allow a hyphen in
key names.  Previously, the "Backup-Intent" field was being ignored because
its name was considered invalid; this change should fix that.

Store unspecified scheme names in database as empty string, not null.

Avoid the use of nulls to represent an unspecified backup scheme in the
local database.  This should fix the bug where database cleaning would not
touch backups without a scheme name.

Delete obsolete sub-block signatures when garbage collecting.

Update NEWS file the 0.7 release.

Note the addition of the sub-file incrementals feature, and include a
script for upgrading the local database to the new format.

Fix a bug in signature loading for sub-file incrementals.

Signatures for sub-file chunks were being written properly, but were not
being loaded properly (signature data and the algorithm string were
being swapped), so no sub-file incrementals were being generated.

Track quantity of data referenced in old segments more precisely.

When calculating used space in segments, treat a reference to just a subset
of data in an object (for example, with subfile incrementals) as using just
that data, instead of the entire object.  This should provide better
information to the segment cleaner.

Initial support for efficient sub-file incrementals.

This is a cleaned-up version of the code written for the OSDI'08
submission to implement sub-file incremental deltas.  Large files are
broken into small chunks (in a content-sensitive manner with Rabin
fingerprints, as in LBFS).  Hash values are computed for the chunks and
stored in a new database table in the local database.  On subsequent
backups, when a file has changed, search for chunks that are identical,
so that portions of old blocks may be re-used even if the entire blocks
cannot be.

Remove some debugging output so backup runs are less verbose.

Put updated copyright statements in all source files.

These now reflect the fact that all code should be distributable under the
GPLv2.

Report compressed size of data written in a backup as well as uncompressed.

When exiting, a summary of the size of all segments (grouped by type: data,
metadata, ...) is printed.  Extend this so that both the uncompressed and
compressed sizes of the segments are printed, and to do so now also keep
track of the compressed size of data.

Update copyright dates in source files.

Squeeze extra blank lines when dumping metadata logs.

In lbs-util, squeeze out extra blank lines in the output of the
read-metadata command.  Extra blank lines may appear in the input,
particularly when delta-encoding metadata logs, but to produce
uniform-looking outputs, delete these extra blank lines.

NEWS updates.

Update arguments passed to upload script.

Fix the remote upload script implementation in lbs so that it matches the
conventions expected by the S3 sample script.

Implement a simple backend script to store data to Amazon S3.

This currently doesn't quite use the interface expected by lbs.  The
interfaces will be matched soon.

Preliminary support for external file upload scripts.

This adds initial support for calling out to an external script to transfer
files to a backup server.  Storage requirements on the client using this
are minimal: space for the local database and for spooling several files
for upload.  Local temporary files are deleted as they are uploaded, and
the backup rate is throttled to the upload rate.

Initial framework for direct transfer of backups to remote storage.

Add a layer of indirection in the writing of files to the backup store, and
create a background thread to handle the processing of files to be stored.
Right now this secondary thread does not do much, but will easily be able
to launch a helper script for transferring data to a remote server.

Files are processed by the background thread one at a time.  Multiple files
can be queued up for processing, but the size of the queue is limited so
that the production of backup data will be throttled to the speed at which
the data can be transferred (to bound the temporary space needed for
storing files).

Make restoring from snapshots more efficient.

When restoring a snapshot, restore files in order roughly determined by how
they are stored in segments, instead of in pure lexicographic order.  This
should ensure that, for the most part, each segment only has to be unpacked
once, instead of perhaps many times as could happen previously, and so
should make restoring more efficient.

This implementation loads all metadata into memory to determine the
ordering, and so restores are now much more memory-intensive than before.
It would be good to work on memory requirements later--either offer an
option to use the old behavior, or perhaps load some of the data into a
temporary database.

Allow restores of just selected files/directories.

Previously, only a complete snapshot could be restored.  This change to
lbs-util will allow just selected data to be restored.

Documentation updates.

Add GPLv2 license conditions.

Since some code is derived from GPL-covered software, allow the entire
program to be distributed under the terms of the GPL, version 2.

Minor documentation updates.

Do not attempt to clean the same segment multiple times.

Slight tweaks to the local database to improve cleaning procedures.

In addition to marking objects in cleaned segments, mark the segment itself
as cleaned.

Include snapshot intent value in the backup descriptor.

It wasn't included earlier, but could be useful to have when actually going
back to clean out old snapshots at a later point in time.

Documentation updates.

Fix to segment age calculation in local database.

It seems that in SQLite, max(x, NULL) yields NULL, not x.  This was being
used to set the mtime of a segment to the maximum mtime of any object in
it, starting with an mtime of NULL.  Fix the computation so it does the
right thing.

Extend tracking of used segments to cover metadata segments.

In the segments_used table in the local database, include segments that
contain metadata in addition to data segments.  Additionally, slightly
extend the segment tracking code so that the modification time of segments
is written out.

The exact utilization of the metadata segments is not yet computed; for now
the utilization is listed as 1.0 even if it is actually less.

Minor fix to segment cleaning.

Previously, all objects were marked to be rewritten, instead of merely
those in segments marked for cleaning.  Properly handle this.

Add a flag to force a full rewrite of the metadata log in a snapshot.

When --full-metadata is given, no pointers to old metadata will be written
out.  This could be used periodically in backups (say, weekly) to prevent
long dependencies in the metadata logs, at least until better cleaning is
implemented.

Add intent-based cleaning to lbs-util.

Allow the level of segment cleaning performed to be adjusted by specifying
the next type of backup to be performed.  If the next backup is to be
longer-lived, then clean more aggressively.

Fix a bug in computing the size of a segment that led to utilization > 1.0.

The old code for computing the size of a segment (to be stored in the
segments table) could leave off the last object to be written to the
segment.  This could cause the computed segment utilization to be greater
than 1.0, which should be impossible.  Fix the size calculation so that it
should always include all data written to the segment.  As a bonus, this
also correctly computes the size of metadata-log segments, even though the
metadata objects don't appear in the block_index table (which was
previously used for computing the segment size, but is no longer).

Fix a bug that caused blocks not to be properly re-used on checksum match.

Fix uninitialized variable warning in sample restore program.

Include sizes in references to blocks in each file's data list.

This optimization is aimed at large files that are composed of many
blocks--including the size of each block allows a restore program to
determine the offset at which each block begins in the output file (by
adding up the sizes of the previous block).  This may allow for more
efficient restores, in which file data is filled in as blocks are
encountered, instead of having to find the blocks in the order they appear
in the data list.

A future change might be to only include the sizes when necessary--files
which are composed of a single object do not need a size, nor does the last
block of a large file.  But for now, simply include the size on all
objects.

This is part of a recommended format change, but one that is both forward-
and backward-compatible.

Snapshot format change: extend the slice syntax with a length-only form.

Change slice format so that in addition to <start>+<length>, it is possible
to specify just <length>.  This isn't needed (0+<length>) could be used
instead, but looks more pleasing if lengths are specified more frequently
on objects.  Also update the various tools to correctly parse the new
syntax.

This is part of the new v0.6 format.

When verifying a snapshot, check that the segment list is accurate.

This should help find bugs such as the one fixed in commit 1b39ce3ff11a.

Add "intent" field to a snapshot.

This field is intended to indicate how long the backup might be kept or
what backup schedule the given snapshot is part of--for example 1 for a
daily backup, 7 for a weekly backup.

This might be used when performing segment cleaning or deleting old
snapshots, but for now the information is just stored in the local
database.

Ensure that segments with reused metadata are listed in root descriptor.

Add format support for efficient sparse file handling.

While making other format changes, also add in support for explicitly
representing regions of a file that are entirely zero, as can happen with
sparse files.  These are represented with an object reference of the form
"zero[0+<length>]".  Update the lbs tool to generate and parse these
references, and the utility code to also handle it.

The restore tools do not seek over zero regions when writing out a file, so
the file is not restored as a sparse file, but that support can easily be
added later with no change needed to the format.

Upgrades to utility code for new formats, and a few more database tweaks.

Update the sample restore script and the Python code to support the new
snapshot format and the new local database schema.  While updating segment
cleaning, also slightly rearrange the database schema to better support it.

Update the NEWS file with some information about format changes.

Drop the obsolete snapshot_contents table from the local database.

Provide a script for converting the local database to the v0.6 format.

Modifications to the local database: create a summary segments_used table.

Make the local database more compact by only storing, for each snapshot, a
listing of the segments it uses and the fraction of each which is used,
instead of listing all objects referenced individually.

This commit only adds the new table; it doesn't yet delete the old table
(snapshot_contents).

Flag "volatile" files when creating a snapshot.

If a file has changed very near to the time it was backed up (right now 30
seconds, though this could probably be decreased to only a few seconds),
mark the file as "volatile" and do not use the stat information to skip
that file on the next backup.  This is to avoid a race condition where a
file's stat information is saved, the file is dumped, and then the file is
modified again.  If this happens within the same second as the earlier
modifications, then mtime and ctime will not be updated (since they already
refer to the current second), and on a subsequent backup the file would not
be stored since it appears to be unchanged.  However, if the file's mtime
and ctime are in the past, then this can't happen, so use this as a test
for when it is safe to skip apparently unchanged files.

The volatile flag only needs to go in the statcache, not the main metadata
log, but for the moment it is going in both.

Assorted minor code cleanups.

Ensure the "name:" key shows up first in metadata output.

This isn't necessary, but is nice for readability.

Partially revert metadata format changes in 6c94114148c4.

On second thought, the renaming of the "name:" field to "path:" isn't worth
the trouble of making the change since there isn't much benefit and
updating tools to deal with either format will be more complex.  The other
changes can be left since they are smaller and easier to support.

Revert this now, before any releases are made with the change in effect.

Drop the old statcache implementation.

The statcache is now replaced with the unified local metadata log, which is
used to aid in reusing unchanged parts of the metadata log in snapshots,
but additionally contains all the information needed to determine if a file
is unchanged.

Initial implementation of metadata log sharing.

Allow metadata written to segments to be reused between snapshots.  Keep
track of what metadata was written out on the client, and when identicial
metadata would be written on a subsequent backup, instead emit a reference
to the old metadata.

This needs more testing and verification.  There also needs to be a
mechanism for performing the equivalent of segment cleaning for metadata,
so that the metadata log does not become excessively fragmented over time.

Bugfix for splitting the metadata log in the new metadata code.

Write out new-style statcache data.

Write out statcache-style data from the metadata logging module of lbs.
This will eventually replace the old statcache implementation, but is not
complete.  This new statcache data is not yet read in or used elsewhere.

In the new format, the data in the statcache file has the same format as
the data in the metadata log itself.  Each stanza with file information is
prefixed with a @@reference line that gives a reference to the location of
the metadata.  If the metadata has not changed, this will allow metadata
log data to be re-used between snapshots.

Drop the use of indirect blocks for storing pointers to data.

Now store the entire list of blocks that contain each file's contents
inline in the metadata log, even when that list is large.  Previously, the
list was split out into a separate object when it contained more than 8
entries.  These indirect blocks may still be useful, but they also
complicate the metadata/statcache rewrite, so for the moment disable them.
They may be reintroduced later.

Initial refactoring of metadata logging.

Move the writing of entries in the metadata log to a separate class in a
separate file (MetadataWriter in metadata.cc).  This is the first step of
the changes, which moves the existing code but does not significantly
change it.  It is preparation for more significant changes to metadata
writing.

Changes to the metadata log format.

A small collection of changes to make the snapshot format a little more
rational (I hope).  The intent is to also more or less merge the formats of
the metadata log and statcache.  There will likely be other changes in the
future in the course of working on metadata scalability.  The format is not
yet finalized!

WARNING: These changes will require new tools to read the generated backup
snapshots.  The version number in the format has been updated.  This
changeset does not include the necessary changes to the snapshot-parsing
code.

NEWS updates for 0.5.1 release (minor changes only).

Provide a sample tool, contrib/parity-gen, for RAID-like parity sets.

parity-gen will use the par2 command to generate redundant data files, to
be stored with backup segments, that will allow segments to recover even if
some of the data is lost or damaged.  When given a directory, it will
incrementally update parity sets to reflect changes made to the directory
since the last run.

This tool is still under development, and shouldn't be completely trusted
yet.

Check LBS format version when reading snapshots in the tools.

Have the lbs-util command check the version of a snapshot when it is read,
and signal an error if the version is newer than what is supported, so that
silent failures do not occur if the format is changed in the future.

lbs-util: Add a command for dumping a flattened metadata log file.

Minor documemtation update.

LBS v0.5 release.

Fix mismatched new/delete calls.

Caught by Valgrind: memory was being allocated with new[] but freed with
delete.  Use delete[] instead.

Make extraction of segments in lbs.py even more quiet.

Add a restore-snapshot command to lbs-util.

This is still in development, and not fully tested yet.  This is meant to
mostly replace restore.pl, and will eventually have more features (it can
already restore without needing all segments unpacked first).

The restore.pl script won't go away, though, since it is still useful to
include as a small, self-contained bare-bones restore program.

Add "prune database" command to lbs-util.

This acts like clean, but doesn't perform the step of marking old segments
as expired.

File reorganization: move non-essential binaries to contrib/.

The top-level directory is now mostly for the main lbs binary, and the
lbs-util script.  Other scripts, which are not necessary for backups (but
helpful) can be found in contrib.

When cleaning the cache of objects, don't be so verbose.

Change the command for cleaning from "rm -rv", dropping the "-v".

Enhance object-checksums command.

If no segments are specified, dump object checksums for all segments.
Additionally, prompt for a password (to decrypt segments) when needed.

Move most documentation into a doc/ subdirectory.

Remove cleandb.sql SQL script since this functionality is now in lbs-util.

Rename lbs-util.py to lbs-util.

The Python implementation is now the standard utility program for working
with LBS archives.  Drop the ".py" suffix.  It replaces the old lbs-util
program, which was implemented in Perl.

Delete the Perl LBS module and the Perl-based lbs-util script.

Expanded Python module for accessing LBS snapshots, and lbs-util.py.

Expand the lbs Python module with code for reading from LBS archives.  This
includes decoding segments and parsing snapshot descriptors and metadata
logs.

Expand the lbs-util.py tool so that it has most of the functionality of
lbs-util (Perl implementation).  The Perl code should now be considered
deprecated, and will be removed at some point in the future.

The Python code still needs some cleaning up.

Suppress error messages from Makefile when git-describe is not available.

README spelling corrections.

NEWS file updates in preparation for v0.4 release.

Preview of a new Python-based management tool; includes segment cleaning.

This adds a Python-based lbs-util program which can perform automatic
segment cleaning.  This hasn't been entirely worked out yet, so it may yet
be a little buggy, and the policies implemented can certainly be improved.
Expect future improvements in this area, and don't yet rely on it too
heavily.

Documentation improvements.

Highlights are a README file with instructions for getting started, and
description of some implementation details, starting with the purpose and
format of the local database.

Place expired and repacked objects into segments based on database.

The local database can store an integer with each expired object that can
be used to group objects together based on age or other factors.  Update
the lbs snapshot utility to place objects into segments based on this
value.

Implement --signature-filter for signing backup snapshots.

If supplied, the argument to --signature-filter will be a program through
which the text for the root snapshot descriptor is filtered.  This filter
should act much like "gpg --clearsign": produce a nearly-identical text
file, with perhaps a few lines at the start or end containing the
signature, but which can be treated as an ordinary segment descriptor by
ignoring this leading and trailing data.

lbs-util now supports reading encrypted segments (with lbs-filter-gpg).

Change the default to encrypted segments rather than compressed with bzip2.
The default of the lbs program has not been changed; it is still necessary
to specify the correct options there to generate encrypted backups.