On 2014-09-19 08:18, Rob Spanton wrote: > Hi, > > I have a particularly uncomplicated setup (a desktop PC with a hard > disk) and I'm seeing particularly slow performance from btrfs. A `git > status` in the linux source tree takes about 46 seconds after dropping > caches, whereas on other machines using ext4 this takes about 13s. My > mail client (evolution) also seems to perform particularly poorly on > this setup, and my hunch is that it's spending a lot of time waiting on > the filesystem. > > I've tried mounting with noatime, and this has had no effect. Anyone > got any ideas? > > Here are the things that the wiki page asked for [1]: > > uname -a: > > Linux zarniwoop.blob 3.16.2-200.fc20.x86_64 #1 SMP Mon Sep 8 > 11:54:45 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > > btrfs --version: > > Btrfs v3.16 > > btrfs fi show: > > Label: 'fedora' uuid: 717c0a1b-815c-4e6a-86c0-60b921e84d75 > Total devices 1 FS bytes used 1.49TiB > devid 1 size 2.72TiB used 1.50TiB path /dev/sda4 > > Btrfs v3.16 > > btrfs fi df /: > > Data, single: total=1.48TiB, used=1.48TiB > System, DUP: total=32.00MiB, used=208.00KiB > Metadata, DUP: total=11.50GiB, used=10.43GiB > unknown, single: total=512.00MiB, used=0.00 > > dmesg dump is attached. > > Please CC any responses to me, as I'm not subscribed to the list. > > Cheers, > > Rob > > [1] https://btrfs.wiki.kernel.org/index.php/Btrfs_mailing_list > > WRT the performance of Evolution, the issue is probably fragmentation of the data files. If you run the command: # btrfs fi defrag -rv /home you should see some improvement in evolution performance (until you get any new mail that is). Evolution (like most graphical e-mail clients these days) uses sqlite for data storage, and sqlite database files are one of the known pathological cases for COW filesystems in general; the solution is to mark the files as NOCOW (see the info about VM images in [1] and [2], the same suggestions apply to database files). As for git, I haven't seen any performance issues specific to BTRFS; are you using any compress= mount option? zlib based compression is known to cause serious slowdowns. I don't think that git uses any kind of database for data storage. Also, if the performance comparison is from other systems, unless those systems have the EXACT same hardware configuration, they aren't really a good comparison. Unless the pc this is on is a relatively recent system (less than a year or two old), it may just be hardware that is the performance bottleneck.