I'm using 1.6.x. I wasn't aware that there'd been sufficient server-side work in 1.7.x as to make this distinction important.
// ben On Mon, Sep 12, 2011 at 16:12, Daniel Shahaf <d...@daniel.shahaf.name> wrote: > You haven't mentioned what version of svn you use. As you say, there > has been work recently --- some of it is in 1.7, some of it is on > ^/subversion/branches/performance, some of it is on > ^/subversion/branches/revprop-packing, and some additional ideas > are in notes/fsfs-improvements.txt in trunk. > > Ben Smith-Mannschott wrote on Mon, Sep 12, 2011 at 15:44:20 +0200: >> I've made the observation that FSFS repositories perform better on >> EXT4 than BTRFS. This probably isn't ground-breaking, but I thought >> I'd share it. >> >> I've got two Linux machines: >> >> - colossus, using BTRFS spanned over two disks. >> 2.6.38-11-generic #48-Ubuntu SMP Fri Jul 29 19:02:55 UTC 2011 >> x86_64 x86_64 x86_64 GNU/Linux >> >> - oberon, using EXT4 on a 2-disk software RAID-1 set. >> Linux oberon 2.6.32-33-generic #72-Ubuntu SMP Fri Jul 29 21:07:13 UTC 2011 >> x86_64 GNU/Linux >> >> I've noticed that writes to FSFS repositories are 5x faster under EXT4 >> than BTRFS. When svnsyncing form the same svn:// source to an local >> repository (file://), oberon completes about 400 revisions in the time >> it takes colossus to grind through 80. >> >> The BTRFS machine is our build server. Performance with (1.6.x) >> working copies is quite acceptable, but I'm glad I'm not using it to >> host svn repositories. >> >> Looks like the BTRFS people have some work to do. Maybe current >> Kernels have already improved this picture. I know there has been >> recent work on reducing the cost of meta-data operations (e.g. file >> creation, ...) and that work is ongoing on defragmentation >> functionality because of poor performance on files that are modified >> in place heavily (e.g. sqlite). >> >> // ben >