Measured: btrfs COW and sqlite exclusive locking

Out of curiosity, I modified the svn client to use the btrfs facility
for fast file copies (copy-on-write, also known as reflink), to see
what benefits it might possibly give in terms of performance and disk
space. While at it, I also measured the benefits of the sqlite
exclusive locking that everybody have been taking about lately, to see
if it really makes a difference on fast file systems.

Using the btrfs COW mechanism will make the copied files share the
data on disk in a transparent way, and is implemented in cp(1) from
the GNU coreutils (the --reflink option). Since the bulk of a working
tree typically consists of duplicated files, this seems very attractive.

The changes were straightforward; please tell me if you want to see
the patches.

All tests were done against a dedicated svnserve on another machine.
The tree is a typical medium-sized source tree: 27000 files and
directories, 263 MiB in total (.svn metadata and pristine storage not
included).

The client is based on a fairly recent 1.7.x (r1357273). The server
runs 1.6.16.

Times for checking out a fresh tree, in seconds:

               default exclusive locking
btrfs 26.4 19.1
btrfs + COW 28.8 21.3
ext4 28.7 19.4
tmpfs 16.7 13.9
nfs 743.2 143.2

The biggest surprise was that COW actually made the checkout slightly
slower, even though no "true" file copies were made. I'm not sure how
to explain this---perhaps everything is already in cache so the copies
aren't very expensive, or the COW operations are somehow
synchronising? More research is clearly needed. Free-standing tests on
large files show that COW copies are much faster than moving the bits
using read/write.

However, the disk usage (as reported by df(1)) was almost halved with
COW, as expected:

               disk usage (MiB)
btrfs 573
btrfs + COW 361

These savings could very well be worth the performance penalties.

Also interesting were the gains of exclusive sqlite locking even on
fast local file systems. Not only does NFS go from unusably slow to
barely tolerable, even on tmpfs do we see substantial improvements. No
question about it: for the next production svn build here, I'm turning
on exclusive locking by default!

Times for a null update (hot cache):

              default exclusive locking
btrfs 0.71 0.68
ext4 0.68 0.65
tmpfs 0.68 0.65
nfs 9.0 2.3

Times for a slightly less null update (1000 revisions, roughly as many
files changed):

              default exclusive locking
btrfs 3.2 2.7
btrfs + COW 4.0 3.5
ext4 2.8 2.6
tmpfs 2.6 2.5
nfs 73.7 15.3
Received on 2012-07-08 18:47:52 CEST