Chris Murphy wrote: >I suggest reproducing the problem and issuing sysrq+w and then post >the entire resulting output for a developer to evaluate. I find it's
I'll give that a try. >I see this is btrfs-receive workload, so I wouldn't guess it's >suvolume lock contention unless the contention is happening with a >single shared parent subvolume into which all the receive subvolumes >are going (e.g. subvol id 5). I'm not sure how to alleviate it. Well, machine A has 32GB RAM and is running multiple simultaneous btrfs-receive instances, but the machine rarely locks up unless I increase the total reception rate beyond 5MB/s. Machine B has 8GB RAM and is running at most a single btrfs-receive instance, but it is much more susceptible to hangups. The maximum reception rate here is 3MB/s. In both cases all received subvolumes are created inside the same master parent (subvol id 5). The only difference is that machine A receives multiple subvolumes simultaneously, and machine B serialises reception (it basically receives subvolumes from a single source (machine A)), but the subvolumes here *are* created back to back (so maybe the previous btrfs-receive is still late flushing buffers to disk when the new btrfs-receive already starts). -- Stephen.
