I noticed a huge performance hit while trying to dedupe BTRFS snapshots. When Duperemove tries to dedupe 80 copies of a Debian ISO file, it takes a very, very long time, even if it's already deduped.
So I made some tests. I took two ref linked 3GB files, saved their extends, then used Duperemove (no hashfile) on the two files with debug enabled.
During the dedupe phase, multiple ioctl requests have been made.
I then compared the new extends, and they are the exact same as before.
So Duperemove is trying to call ioctl on the same extents, being wasteful, and slowing down deduping large snapshot folders.
I noticed a huge performance hit while trying to dedupe BTRFS snapshots. When Duperemove tries to dedupe 80 copies of a Debian ISO file, it takes a very, very long time, even if it's already deduped.
So I made some tests. I took two ref linked 3GB files, saved their extends, then used Duperemove (no hashfile) on the two files with debug enabled. During the dedupe phase, multiple ioctl requests have been made. I then compared the new extends, and they are the exact same as before.
So Duperemove is trying to call ioctl on the same extents, being wasteful, and slowing down deduping large snapshot folders.