| 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 |
Archives