btrfs-progs VS jdupes

Not an error I've seen before or that makes much sense to me at first glance, might want to take this to https://github.com/kdave/btrfs-progs/issues or the mailing list?

You can test it by allocating the space to see if it can use it all: e.g. fallocate -l 3.8t /mnt/elfstone2/butts should succeed. If it does, then it's probably fine even if the balance didn't do what it should have. If not and you run out of space with some unallocated space left on only one device, not so much. If its the same bug I saw that means if your fs was created pre kernel 5.19, it will not allocate correctly on >5.19 until the array is rebuilt under the newer kernel.

Mount options should be documented either at https://btrfs.readthedocs.io/en/latest/Administration.html or at the manual page section 5 (man 5 btrfs). Autodefrag is in section https://btrfs.readthedocs.io/en/latest/Administration.html#btrfs-specific-mount-options . In case you find more information missing, unclear, lacking cross-references please open an issue at https://github.com/kdave/btrfs-progs/issues .

thanks. I filled a feature request... https://github.com/kdave/btrfs-progs/issues/610

Resume sort of doesn't work, when you resumed it will have started a fresh balance with a high usage value (check your syslog to confirm).

That's the hint. It's an unfixed bug with the accounting when scrub is paused and resumed, the relevant issue is I think https://github.com/kdave/btrfs-progs/issues/227 .

[1] - https://github.com/kdave/btrfs-progs/issues/277

Hoping for a filesystem clone option at some point.

I recommend the use of jdupes, a fork of the well-known fdupes, to find duplicate files.

200 lines of Nim [1] seems to run about 9X faster than the 8000 lines of C in fdupes on a little test dir I have. If you need C, I think jdupes [2] is faster as @TacticalCoder points out a couple of times here. In my testing, `dups` is usually faster than `jdupes`, though.

[1] https://github.com/c-blake/bu/blob/main/dups.nim

[2] https://github.com/jbruchon/jdupes

There's always the well-respected tool, Czkawka. Or, of the CLI is your thing, jdupes is a good option.

My research into this many years ago turned out that jdupes was the right / best solution I could find for my usecase.

https://github.com/jbruchon/jdupes

Though that works fine from a script perspective I'd like some more interactive way of sorting directories etc. Identifying is just the first step, jdupes helps with linking the files (both soft and hard links comes with caveats though!) but that is mostly to save space, not to help in reorganisation.

I can work it out by looking at https://github.com/jbruchon/jdupes.

I have looked at a few alternatives and think jdupes is the one for me. Then I found out it was not multi-threaded so will give it a go but the developer of jdupes recomended fclones (https://github.com/jbruchon/jdupes/issues/186) if you were dealing with large file systems and wanted multi-threading. But as I am using a HD it may not be necessary.

jdupes is a fork of the old standby fdupes, but it has a Win32 release as well as supporting POSIX.

jdupes is a tuned fork of the well-known fdupes, and has Win32 releases.