On 2014-09-19 08:49, Austin S Hemmelgarn wrote:
> 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.
>
Realized after I sent this that I forgot the links for [1] and [2]

[1] https://btrfs.wiki.kernel.org/index.php/UseCases
[2] https://btrfs.wiki.kernel.org/index.php/FAQ