On Tue, Jan 14, 2014 at 06:34:19PM +0100, David Sterba wrote:
> On Mon, Dec 30, 2013 at 04:12:55PM +0800, Liu Bo wrote:
> > --- a/ctree.h
> > +++ b/ctree.h
> > @@ -470,6 +470,7 @@ struct btrfs_super_block {
> > #define BTRFS_FEATURE_INCOMPAT_EXTENDED_IREF (1ULL << 6)
> > #define BTRFS_FEATURE_INCOMPAT_RAID56 (1ULL << 7)
> > #define BTRFS_FEATURE_INCOMPAT_SKINNY_METADATA (1ULL << 8)
> > +#define BTRFS_FEATURE_INCOMPAT_DEDUP (1ULL << 9)
>
> FYI, this incompat bit is taken by Josef's NO_HOLE feature, now heading
> to next merge window, so I've used 10 for dedup in integration branch.
Thanks for the notice, David, I'll update it in the next version.
>
> > --- a/ioctl.h
> > +++ b/ioctl.h
> > @@ -430,6 +430,15 @@ struct btrfs_ioctl_get_dev_stats {
> > __u64 unused[128 - 2 - BTRFS_DEV_STAT_VALUES_MAX]; /* pad to 1k */
> > };
> >
> > +/* deduplication control ioctl modes */
> > +#define BTRFS_DEDUP_CTL_ENABLE 1
> > +#define BTRFS_DEDUP_CTL_DISABLE 2
> > +#define BTRFS_DEDUP_CTL_SET_BS 3
> > +struct btrfs_ioctl_dedup_args {
> > + __u64 cmd;
> > + __u64 bs;
>
> I've spotted that you did not reserve any space for future extensions of
> the ioctl, especially the in-band dedup can be quite heavy, I think
> we'll want some tunables in the future.
>
Good point, I think 128 bytes can be enough for that, agree?
I didn't put much notice on that because I kept stuck in fixing more urgent
ENOSPC
problem, it looks like I can hardly bypass this endless issue with dedup
enabled,
I have to fix it thoroughly...
Thanks,
-liubo
--
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
