[gentoo-user] Btrfs: how to fix slow sequential write performance?

[gentoo-user] Btrfs: how to fix slow sequential write performance?

[Marc Stürmer]

Greetings fellow Gentooistas,

at the moment I am doing some testing and evaluating of Btrfs on my own 
system. Why? Just because I can and I am curious about it.

Because I am doing that for evaluation purpose please don't give advise 
like "go ZFS" or something like that, thank you.

Kernel is 3.10.7, the file system is on one hard drive only (SATA).

And here comes my question: sequential write access seems to be slow as 
hell, actually something around like 10 Mbyte/s according to dd's output.

The same HDD performed under ext4 with around 90 Mbyte/s.

Command is something like: dd if=/dev/zero of=file.img bs=1G count=150

Nothing else is running at the time of writing, no scrub/balance on the 
file system or other process eating up much cpu time.

Mount option is "relatime" only. So is this a well known issue only with 
this kernel or generally with this file system at the moment?

Are there any possible fixes to squeeze better performance out of it or 
is this unlikely to happen so that I should better take that into 
account of my evaluation and maybe dump it then?

Thanks in advance.

Re: [gentoo-user] Btrfs: how to fix slow sequential write performance?

[William Kenworthy]

On 25/09/13 16:54, Marc Stürmer wrote:
> Greetings fellow Gentooistas,
> 
> at the moment I am doing some testing and evaluating of Btrfs on my own
> system. Why? Just because I can and I am curious about it.
> 
> Because I am doing that for evaluation purpose please don't give advise
> like "go ZFS" or something like that, thank you.
> 
> Kernel is 3.10.7, the file system is on one hard drive only (SATA).
> 
> And here comes my question: sequential write access seems to be slow as
> hell, actually something around like 10 Mbyte/s according to dd's output.
> 
> The same HDD performed under ext4 with around 90 Mbyte/s.
> 
> Command is something like: dd if=/dev/zero of=file.img bs=1G count=150
> 
> Nothing else is running at the time of writing, no scrub/balance on the
> file system or other process eating up much cpu time.
> 
> Mount option is "relatime" only. So is this a well known issue only with
> this kernel or generally with this file system at the moment?
> 
> Are there any possible fixes to squeeze better performance out of it or
> is this unlikely to happen so that I should better take that into
> account of my evaluation and maybe dump it then?
> 
> Thanks in advance.
> 

How old is the fs? - I am ran into a major slowdown due to COW snapshot
fragmentation (VMs on ceph using btrfs) - a known problem.  Using that
kernel is also giving me an eventual hard lockup if I try and do a
recursive defrag (on another system), but the ssd on an apple air
defraged fine.

btrfs is also seems very sensitive to how full it is.  Have you tried a
btrfsck? - some errors seem to cause slowdowns as well.

BillK