On Fri, Nov 22, 2019 at 03:36:43PM +0100, Christian Pernegger wrote: > Am Do., 21. Nov. 2019 um 23:22 Uhr schrieb Zygo Blaxell > <ce3g8jdj@xxxxxxxxxxxxxxxxxxxxx>: > > Snapshot delete is pretty aggressive with IO [...] can effectively hang for a few minutes > > while btrfs-cleaner runs. > > It's doesn't look like it's btrfs-cleaner that blocks here, though, > more like it's btrfs-transacti. It's hard to tell. btrfs-transaction does a lot of work for other threads. If you have kernel stacks enabled, watch -n.1 cat /proc/<pid of btrfs-cleaner>/stack will show you what btrfs-cleaner is up to. If it's something like 'wait_for_commit' then btrfs-cleaner dumped a bunch of work on btrfs-transaction, and now btrfs-transaction is trying to catch up. > > Snapshot create has unbounded running time on 5.0 kernels. > > It looks to me like delete, not create, is the culprit here. > > > Anything that needs to take a sb_writer lock (which is almost everything > > that modifies the filesystem) will hang until the snapshot create is done; > > It's not just fs activity, either. Even if I'm just typing in > LibreOffice or at a bash prompt, the input isn't registered during the > freeze (it's buffered, so it comes out all at once in the end). IO pressure, especially blocked writes, can delay memory allocations on Linux. That stops almost everything dead in a modern GUI. If you can log into the box from another machine you might be able to watch what it's doing with 'top' etc. On the other hand, from the other messages in this thread, it sounds like you're using qgroups, which multiplies everything I said above by 1000. qgroups is all in-kernel CPU, too, so userspace can't preempt it. > Cheers, > C.
Attachment:
signature.asc
Description: PGP signature
