You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is most likely not the right place to mention this, but I didn't manage to find the mailing list.
I've found that mounting the filesystem to deduplicate with the sync (synchronous IO) option can help prevent hanging and kernel timeouts which I've seen mentioned in none of the other issues about hanging.
Has the thrashing aspect of async IO been looked at as a factor so far?
The text was updated successfully, but these errors were encountered:
Something that has helped me was schedtool -D ionice -c 3 duperemove ... which puts duperemove under CPU and IO idle priority policies.
If you're deduping HDDs then limiting it to 1 IO thread might also help because parallelism tends to make access more random and HDDs prefer more sequential IO patterns.
Another option is to use cgroups to set io.max or cpu.max policies
Hello @auroraanon38
Your issue is quite strange to me
Could you reproduce the issue with the latest code, without using the sync mount option ?
If you do reproduce, could you give me your kernel version and the btrfs-tools version used to create the filesystem ?
This is most likely not the right place to mention this, but I didn't manage to find the mailing list.
I've found that mounting the filesystem to deduplicate with the
sync
(synchronous IO) option can help prevent hanging and kernel timeouts which I've seen mentioned in none of the other issues about hanging.Has the thrashing aspect of async IO been looked at as a factor so far?
The text was updated successfully, but these errors were encountered: