Closed matthiaskrgr closed 4 years ago
For me it also does not work anymore. I'm using xfsprogs 5.0.0-1.4 and linux 5.3.7-1 on OpenSUSE. It found 0 identical extents but before I copied a file.
While the current master branch does not work for me, v0.11.1 works on CentOS 8 for me.
Ah, yes. For me too. I just gave it a try. Thank you!
I just ran into this issue on master. I've only glanced at the code but I think this might be because the last commit (128acd99fc4ff1c6735083ffd69951ba9d7c997e) causes csum_extent
to return 0 when csum_by_block
/csum_by_extent
still interpret 0 as EOF, so it just gives up on each file after trying the first extent.
Edit: Well, there's probably a deeper issue still. If I checkout the second-to-last commit it finds two duplicate extents on exact test copies. That's better than 0, but less than the 75 I expected.
I can confirm this issue still persists using the latest master. Using kernel v5.4.2 and xfsprogs v5.2.1,
Quick bisect, c61a144a5f0c0a546a31340808bab122c58b2306 is where this stops working on dev likely (at least for me)
Also noting this is where dev has --dedupe-options= which is likely what you are seeing as a bug, this may just be a miss-understanding of the new options
If so, what would be the proper way to use the tool in order to duplicate (no pun intended) the previous behaviour?
I think it should be --dedupe-options=partial,same
but it does not work. See #216
I have encountered the same problem.
Same issue for me.
Can you retest latest code in master. I believe this should be fixed by 30e5c7a7fd502d55069977f2037b2c26a3aff684
Looks like its working again :)
In this case I will close this issue if there are anymore problems keep reporting them!
I was checking my entire disk and duperemove was not able to dedupe anything which seemed suspicious.
I tried out
cat bigfile > copy; duperemove .
but duperemove did not dedupe anythingso I'm wondering if it is still working. :/
edit: I'm on linux 5.3.7 / btrfs-progs v5.3