> 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.)