[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn hotcopy vs. LVM snapshot

From: Paul Koning <pkoning_at_equallogic.com>
Date: 2005-11-23 01:37:04 CET

>>>>> "Phillip" == Phillip Susi <psusi@cfl.rr.com> writes:

 Phillip> Phil Endecott wrote:
>> I believe that there is some "magic" in the LVM stuff to make this
>> safe, i.e. the filesystem is told to do some sort of flush before
>> the snapshot is taken, or something. The feature is designed
>> specifically for things like backups. (I'm hoping that someone
>> who is reading this will know a definitive answer...)

 Phillip> What you have to remember is that this form of backup is not
 Phillip> much different than yanking out the power cord of a running
 Phillip> system, booting it up from a cd, and then trying to backup
 Phillip> the hard drive. Most things don't handle system crashes
 Phillip> very well.

I would like to think that isn't true. File systems are supposed to
be designed so they can recover from crashes; that has always been the
case. And most file systems nowadays use journaling so recovery is
fast and clean -- no more fsck.

The same goes for a source control system. A source control system
that falls apart if there is a power failure (which is the most common
cause for Linux system crashes) would not be worth using. And from
what I know of Subversion I would expect it to be crash-tolerant.

So while it's true that snapshots will require running the file system
and Subversion crash recovery machinery, that machinery should be

Finally, on some systems there is an API that lets applications
coordinate with Snapshots -- Windows has this in "VSS".


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 23 01:39:43 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.