1 |
On 25/09/13 16:54, Marc Stürmer wrote: |
2 |
> Greetings fellow Gentooistas, |
3 |
> |
4 |
> at the moment I am doing some testing and evaluating of Btrfs on my own |
5 |
> system. Why? Just because I can and I am curious about it. |
6 |
> |
7 |
> Because I am doing that for evaluation purpose please don't give advise |
8 |
> like "go ZFS" or something like that, thank you. |
9 |
> |
10 |
> Kernel is 3.10.7, the file system is on one hard drive only (SATA). |
11 |
> |
12 |
> And here comes my question: sequential write access seems to be slow as |
13 |
> hell, actually something around like 10 Mbyte/s according to dd's output. |
14 |
> |
15 |
> The same HDD performed under ext4 with around 90 Mbyte/s. |
16 |
> |
17 |
> Command is something like: dd if=/dev/zero of=file.img bs=1G count=150 |
18 |
> |
19 |
> Nothing else is running at the time of writing, no scrub/balance on the |
20 |
> file system or other process eating up much cpu time. |
21 |
> |
22 |
> Mount option is "relatime" only. So is this a well known issue only with |
23 |
> this kernel or generally with this file system at the moment? |
24 |
> |
25 |
> Are there any possible fixes to squeeze better performance out of it or |
26 |
> is this unlikely to happen so that I should better take that into |
27 |
> account of my evaluation and maybe dump it then? |
28 |
> |
29 |
> Thanks in advance. |
30 |
> |
31 |
|
32 |
How old is the fs? - I am ran into a major slowdown due to COW snapshot |
33 |
fragmentation (VMs on ceph using btrfs) - a known problem. Using that |
34 |
kernel is also giving me an eventual hard lockup if I try and do a |
35 |
recursive defrag (on another system), but the ssd on an apple air |
36 |
defraged fine. |
37 |
|
38 |
btrfs is also seems very sensitive to how full it is. Have you tried a |
39 |
btrfsck? - some errors seem to cause slowdowns as well. |
40 |
|
41 |
BillK |