Am Freitag, 9. Januar 2015, 11:04:32 schrieb Peter Waller: > Apologies to those receiving this twice. > > On 27 December 2014 at 09:30, Hugo Mills <hugo@xxxxxxxxxxxxx> wrote: > > Now, since you're seeing lockups when the space on your disks is > > > > all allocated I'd say that's a bug. However, you're the *only* person > > > > who's reported this as a regular occurrence. Does this happen with all > > filesystems you have, or just this one? > > I have experienced machine lockups on four separate cloud machines, > and reported it in a few venues. I think I even reported it on this > list in the past but I can't find that right now. Here's a bug report > to Ubuntu-Kernel: > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1349711 > > Regularly rebalancing the machines and ensuring they have >10% free > disk (filesystem) and I don't experience this. Yet I read in this > thread I read that regular rebalancing shouldn't be necessary? > > FWIW, trying to sell BTRFS to my colleagues and they view it as a > stupid filesystem "like the bad old windows days when you had to > regularly defragment". They then go on to say they have never > experienced machine lockups on EXT* (over a fairly significant length > of time). > > So what can I tell them? Are we just hitting a bug which is likely to > get fixed, or must we regularly rebalance? > > .. or is regularly rebalancing incorrect and actually regular machine > lockups are the expected behaviour? :-) I think it should *not* be required. But my practical experience differs from what I think, as I described in great detail here and in this bugreport: [Bug 90401] New: btrfs kworker thread uses up 100% of a Sandybridge core for minutes on random write into big file https://bugzilla.kernel.org/show_bug.cgi?id=90401 So I had these hangs so far *only* when BTRFS was not able to reserve previously unused and unreserved space on the devices for a new chunk, as long as BTRFS can still allocate a new chunk, it stays fast. That said, not in all situation where BTRFS can´t do this, it goes slow. So for me it seems that not having any unreserved device space to allocate chunks from seems to be a *necessary* but no *sufficient* criterion for the kworker uses up 100% of one core issue I reported. I suggest that you add your findings to the bug report and also share details there, as it may help to have more data available on when it happens. That said, still no BTRFS developer looked into the kern.log with Sysrq-T triggers I uploaded there. Robert made a test case which easily triggers the behavior for him, I didn´t yet take time to try out this testcase. Maybe you have a chance to? Its somewhere in this thread as a little shell script. [1] https://bugzilla.kernel.org/show_bug.cgi?id=90401#c0 Thanks, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
