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

Re: What to do when disk is nearly full

From: Jared Hardy <jaredhardy_at_gmail.com>
Date: 2006-05-16 20:53:38 CEST

On 5/16/06, Sinang, Danny <D.Sinang@spi-bpo.com> wrote:
> 1. Move some repositories to NFS partitions

As I understand it, this should be possible using FSFS, but may have
some major performance issues.

> 2. Obliterate old file copies from some repositories ?

My recommendation would be to use svndumpfilter to create two
repositories, split at some revision # that makes sense. Choose a
revision X that corresponds to a date before which most or all
repository data is too "old" to be useful, and make an "old" dump
containing revisions 0-X, and a "new" dump starting at version X and
keeping history through to HEAD. Burn the old dump half to DVDs, or
something suitable for archiving, and start using the new dump repo
exclusively. I personally plan to do something like this soon, except
that the old dump half will stay online (read only) via a slower
server/disk, and the new half will stay on the fast server with RAID
    Note that you may not save much space with this unless there are a
lot of deltas between 0-X that are not actually reflected in the data
of version X. You may be better off splitting your hierarchy into
separate repositories in some logical way, so you can maintain them on
separate storage volumes.

I have also considered experimenting with copying and simlinking old
revision number directories in the FSFS store to a different, slower
(cheaper) storage volume, but maintaining the same path on in the
original FSFS volume. Old revision data never changes, so I'm thinking
it will be accessed far less often, and write access could be safely
limited. I may try using an NFS volume as the slow volume. This is
playing with internals of FSFS data though, so it is probably not safe
to try at home unless you know a lot about the FSFS internal workings.
Definitely don't try this on a production repo without a lot of
experimentation on a backup repo first. Any Devs care to comment on


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue May 16 20:54:57 2006

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.