>>>>> "Dimitri" == Dimitri Papadopoulos-Orfanos <papadopo@shfj.cea.fr> writes:
Dimitri> Hi,
>> I'm trying to understand the need for hot copies before backing up
>> data. I believe I've read through the relevant documentation, but
>> as I understand it transaction commits are atomic, so it's
>> impossible to back up half a revision.
Dimitri> The atomicity of a transaction is achieved through lock
Dimitri> files and such. As a result the transaction seems atomic to
Dimitri> users of Subversion, but that doesn't mean the files in the
Dimitri> Subversion repository are always in a consistent state. For
Dimitri> example what happens if the database is backed up while a
Dimitri> file is locked and being written?
Dimitri> A Subversion transaction is not atomic as far as the OS is
Dimitri> concerned. Only the Subversion user sees the transaction as
Dimitri> an atomic operation through the use of an additional layer
Dimitri> over the OS (Berkeley DB).
That makes sense, but there's an additional angle.
For things to be recoverable, the syscalls have to be done in the
right order, so that a crash at any time leaves the on-disk data in a
state where things can be recovered. It's easy to see how that can be
true for bdb; it's not so obvious with fsfs given that you're
depending on file system ordering and caching then.
In any case, that's how it needs to work. If it does, then a backup
system that uses snapshots (common on storage area networks) would
work, because such a system has "crash consistent semantics".
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Sep 20 15:52:48 2005