On 09/24/15 22:56, Josef Bacik wrote: > We have a mechanism to make sure we don't lose updates for ordered extents that > were logged in the transaction that is currently running. We add the ordered > extent to a transaction list and then the transaction waits on all the ordered > extents in that list. However are substantially large file systems this list > can be extremely large, and can give us soft lockups, since the ordered extents > don't remove themselves from the list when they do complete. > > To fix this we simply add a counter to the transaction that is incremented any > time we have a logged extent that needs to be completed in the current > transaction. Then when the ordered extent finally completes it decrements the > per transaction counter and wakes up the transaction if we are the last ones. > This will eliminate the softlockup. Thanks, Tried this and unexpectedly didn't get any lockups or 'splosions during normal operation, but balance now seems very slow and sits idle most of the time. Running balance without filters on a previously balanced but empty fs: $time btrfs filesystem balance start /mnt/usb Done, had to relocate 3 out of 3 chunks btrfs filesystem balance start /mnt/usb 0.01s user 0.00s system 0% cpu 1:00.91 total On a completely new fs: $mkfs.btrfs -L Test -msingle -dsingle -f /dev/sdf1 $mount /dev/sdf1 /mnt/usb $time btrfs filesystem balance start /mnt/usb Done, had to relocate 4 out of 4 chunks btrfs filesystem balance start /mnt/usb 0.01s user 0.00s system 0% cpu 1:30.88 total Time seems suspiciously in tune with (#chunks) * (tx commits every 30 seconds), maybe needs a few more wakeups? hope this helps :) Holger -- 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
