> Thanks for your answers!
>
>> Nope. Works fine. Between the nightly hot-copy backups and the
>> internal design of the SVN FSFS storage engine, I'm not terribly
>> worried.
>
> I tend to use svnadmin dump for my daily backups.
> (some time ago, I ran into compatibility issues with hotcopy when
> trying to restore on a different OS and it kind of frightened me.)
>
> What would make you prefer to use hotcopy rather than dump? Performance?
>
Inertia. Although we're running all CentOS 5 x86_64, so even if the
machine went down, we would have lots of other choices. But I do need to
look at using svnadmin dump instead.
>> (We took advantage of repository sharding in 1.6, which is why we did a
>> svn dump/load method. If we didn't need sharding, we probably could've
>> just copied the directory tree across from the 1.4 to the 1.6 server.)
>
> Did you consider the type of filesystem when setting up sharding?
> Or would you consider ext3 as good enough?
>
The only time I have problems with ext3 is with the deletion of large
files. The ext3 file system is rather horrid, performance-wise, when you
delete lots and lots of files, or a few really big files. I think it's
trying to update the list of free blocks / inodes, but I'm not sure.
Since a SVN repository (FSFS style) hardly ever deletes lots of files or
large files (except maybe when assembling a 200-400MB check-in?), ext3 is
fine for hosting a repository on. The sharding wasn't even really
necessary for ext3 with directory indexing turned on, but I decided to
play it safe and start sharding to limit the # of rev files in a single
folder.
The bigger performance bottlenecks for us are CPU time, and then maybe
disk reaction time.
(I did not feel the need to go with packed shards, where all of the
revisions get packed into a single file.)
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
