On 2016-01-14 14:26, Liu Bo wrote:
On Thu, Jan 14, 2016 at 11:46:33AM -0500, Austin S. Hemmelgarn wrote:
On 2016-01-14 11:13, James Hogarth wrote:
Hi,
The duperemove[1] tool is in the process for packaging for Fedora at
present but I was wondering what future this may have with the 4.5
dedup patches being proposed.
WIll the btrfs command have the ability to out-of-line dedup files
similar to duperemove (thus negating the need for it) or will this
only control in-line dedup with a tool like duperemove still being
required for periodic only (or restricted path) dedup?
Unless I'm horribly misreading the code, the regular btrfs-progs will not be
adding the ability to do out-of-band deduplication. It may at some point
add a shortcut for the required ioctl to be used from scripts, but that's
probably unlikely.
To avoid memory usage bloat if the btrfs command can order dedup of X
files on the path correctly can it be passed a path to carry the hash
map in some form (similar to how dupeemeove can use sqlite for this)
or is this another use case for the external tool?
This shouldn't be an issue for in-line deduplication, as that's handled in
the kernel.
Finally what's the present situation with regards to defragmentation
and deduplication? Is it safe to turn on autodefrag now when using
snapshots and duperemove? What should the behaviour be with the
proposed 4.5 dedup patches if both inline dedup and autodefrag are
enabled as mount options?
I'm not entirely certain how deduplication would interact with any form of
defragmentation. I'm pretty certain though that autodefrag does properly
handle snapshots, such that the reflinks aren't broken, and it's the
original copy that gets any shared extents defragmented into it.
If it refers to snapshot-aware defrag, it's been disabled, so now btrfs
will not maintain reflinks between snapshots.
I was under the impression that autodefrag had been done separately from
the snapshot-aware manually triggered defrag, and that it's always been
snapshot aware.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
