On Fri, Apr 01, 2016 at 02:37:42PM +0800, Qu Wenruo wrote:
> No much change from previous version.
> 1) Rebased to latest devel branch
>
> 2) Update ctree.h to follow kernel structure change
>
> 3) Update print-tree to follow kernel structure change
>
> Qu Wenruo (7):
> btrfs-progs: Basic framework for dedupe command group
> btrfs-progs: dedupe: Add enable command for dedupe command group
> btrfs-progs: dedupe: Add disable support for inband dedupelication
> btrfs-progs: dedupe: Add status subcommand
> btrfs-progs: Add dedupe feature for mkfs and convert
> btrfs-progs: Add show-super support for new DEDUPE flag
> btrfs-progs: debug-tree: Add dedupe tree support
>
> Wang Xiaoguang (1):
> btrfs-progs: property: add a dedupe property
>
> Documentation/Makefile.in | 1 +
> Documentation/btrfs-dedupe.asciidoc | 150 ++++++++++++++++
> Documentation/btrfs-property.asciidoc | 2 +
> Documentation/btrfs.asciidoc | 4 +
> Documentation/mkfs.btrfs.asciidoc | 9 +
> Makefile.in | 3 +-
> btrfs-completion | 6 +-
> btrfs-convert.c | 19 +-
> btrfs.c | 1 +
> cmds-dedupe.c | 329
> ++++++++++++++++++++++++++++++++++
Can we please have seperate and obvious namespaces for in-band dedupe and
out-of-band dedupe commands? I realize that there is no oob-dedupe
funcationality in btrfs-progs today but I would like to avoid confusing
users in the case that this code hits btrfs-progs.
Specifically by this, I mean I'd like to see anything except 'dedupe' as the
btrfs command, so a user who sees 'btrfs dedupe ....' is not confusing the
two forms we have.
I don't personally care what other name is used and of course it could have
'dedupe' in the name just not solely 'dedupe'. As a poor example, we could
call it 'btrfs inband-dedupe ...'.
Thanks,
--Mark
--
Mark Fasheh
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
