I'm a btrfs user, not a developer; developers can probably provide more
detailed explanation by looking at stack traces in dmesg etc., but it's
possible that there's just no quick fix (yet). I presume these are 1413
_full-volume_ snapshots. Then some operations have to process
43.65TiB*1413=62PiB of data -- well, metadata for that data, but it's
still a lot as you may guess, especially if it's all heavily fragmented.
You can either gradually reduce number of snapshots and wait (it may
drag for weeks and months), or copy everything to a different device and
reformat this one, then don't create that many snapshots again.
As for "blocked for more than 120 seconds" messages in dmesg, I see them
every night after I delete about a dozen of snapshots ~10TiB in _total_
volume, albeit with qgroups. These messages usually subside after about
couple of hours. They only tell you what you already know: some btrfs
operations are painfully slow.
--
With Best Regards,
Marat Khalili
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
