Zygo

The test case is not very representative. Most filesystems do not consist entirely of pairs of duplicate files that are otherwise unique, where each file contains fewer extents than there...

It doesn't look stuck, but it might be looping in `LOGICAL_INO` long enough to mess with RCU (the kernel thread will more or less stop dead). Does bees report detecting...

It might be a normal `LOGICAL_INO` long call time then.

That seems a little extreme for `LOGICAL_INO`, especially on post-5.7 kernels. Also, when I hit the `LOGICAL_INO` slow cases I don't get complaints from RCU. Maybe it's a separate RCU...

I'm giving this the kernel bug label because it obviously is one. Keep the stack traces coming, maybe we can hit something a kernel dev can use. Alternatively, send complete...

Currently bees does not do any defragmentation--in fact, bees *adds* fragmentation where required for better dedupe rates. All of the current btrfs dedupe agents do not choose extents to dedupe...

Sorry, that should be "as of kernel 5.3..." https://github.com/Zygo/bees/issues/115#issuecomment-515485921

OK so it's 5.2.7 (the last patch has been backported to stable/linux-5.2.y)....

It would be better to put that into a thread in bees, since it already has the extent structure cached, and bees knows the extents are unique because it created...

> I think the max extent size is 128M isn't it? That's the absolute maximum, and the useful/practical maximum is much smaller, for _one_ average output extent; however, on rotating...