On 21/07/17 07:06, Paul Jackson wrote: > What in god green's earth can kernel file system code be > doing that takes fifteen minutes (so far, in this case) or > fifty minutes (in the case I first reported on this thread?
I find that just doing a balance on a disk with lots of snapshots can cause this sort of effect. If I understand correctly, this is because btrfs does not have an efficient structure to help find all the references in different subvolumes to an extent which is being manipulated and many trees have to be searched. My understanding may be wrong but, in any case, the effect is that many operations can take massive amounts of processing time if there are lots of shared extents. This caused my early experiments with using btrfs snapshots on my main data disk (full of mail files, etc) to make the system lock up for many **hours** at a time (preventing mail processing, etc). I took the advice on this list to significantly decrease the number of snapshots I kept on the disk (I keep more on a separate backup disk, which has no day-to-day transactions happening, and can also better tolerate any issues). I also created a very hacky script to try to limit the impact of the balances which I do weekly. See https://github.com/GrahamCobb/btrfs-balance-slowly if you are interested. Between these things, the serious disruption is now gone. Note: despite all the hangs, I never saw any disk corruption. Graham -- 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
