1 |
Zac Medico posted on Fri, 24 Feb 2012 20:35:24 -0800 as excerpted: |
2 |
|
3 |
> I've been using btrfs for temp storage, for more than a year |
4 |
|
5 |
> The only problems I've experienced are: |
6 |
> |
7 |
> 1) Intermittent ENOSPC when unpacking lots of files. Maybe this is |
8 |
> related to having compression enabled. I haven't experienced it lately, |
9 |
> so maybe it's fixed in recent kernels. |
10 |
|
11 |
This is one of those "many bugs, same result" bugs. The way btrfs |
12 |
allocates space is /extremely/ complicated, and based on what I read on- |
13 |
list they've been fixing bugs in it, gradually reducing the ENOSPC |
14 |
triggers, for quite some time. |
15 |
|
16 |
Last I read, the biggest remaining known one was indeed related to |
17 |
compression, apparently to a race condition of some sort, with one bit of |
18 |
code reaching the ENOSPC conclusion because it finished before the the |
19 |
actual processing code did. |
20 |
|
21 |
However, apparently same bug could be triggered on uncompressed btrfs if |
22 |
it was stressed enough (rsyncing several gigs was a common duplicator). |
23 |
|
24 |
Last I read they hadn't fully traced that one down in btrfs itself yet, |
25 |
but they had worked around the problem by throttling things further up |
26 |
the stack, in the kernel VFS code I believe. The reasoning was that if a |
27 |
device was so overwhelmed it clearly couldn't keep up, regardless of the |
28 |
filesystem, throttling requests at the vfs level would put less pressure |
29 |
on the filesystem code, allowing things to work smoother. It MAY (my own |
30 |
thought here) have been another application of the buffer-bloat work -- |
31 |
simply increasing buffer size and filling it even more doesn't help, when |
32 |
the bottleneck is further down the stack, rather the reverse! |
33 |
|
34 |
AFAIK that's the present status for 3.3. At least that one spurious |
35 |
ENOSPC trigger remains, but they've worked around it for now with the |
36 |
throttling, so it shouldn't hit anyone but those deliberately disabling |
37 |
the throttling in ordered to further test it, now. |
38 |
|
39 |
But with luck, the stress-testing that Oracle QA's doing ATM will have |
40 |
found the root bug and it's fixed now too. I hope... |
41 |
|
42 |
> 2) Bug 353907 [1] which is fixed in recent kernels and coreutils. |
43 |
> |
44 |
> [1] https://bugs.gentoo.org/show_bug.cgi?id=353907 |
45 |
|
46 |
That one could be another head of the same race-related root bug. In |
47 |
fact, reading it and seeing that ext4 was affected as well, I'm wondering |
48 |
if that's what triggered the introduction of the throttling at the VFS |
49 |
level. |
50 |
|
51 |
(NB: Interesting that I wasn't the only one to see that as an invitation |
52 |
to discuss btrfs. At least my subthread has the subject changed so |
53 |
people that want can ignore it, tho. I wish that had happened here too, |
54 |
but I guess it's kind of late to try and change it with this post, so...) |
55 |
|
56 |
-- |
57 |
Duncan - List replies preferred. No HTML msgs. |
58 |
"Every nonfree program has a lord, a master -- |
59 |
and if you use the program, he is your master." Richard Stallman |