Nicholas D Steeves posted on Tue, 15 Mar 2016 18:08:41 -0400 as excerpted:
> I'm not sure to what degree the following is a relevant concern, and I'm
> guessing it's not, other than for laughs, but to me "dedupe" reads as
> "de-dupe" or "undupe". While it functions as the inverse of the verb
> "t
On 13 March 2016 at 12:55, Duncan <1i5t5.dun...@cox.net> wrote:
> NeilBrown posted on Sun, 13 Mar 2016 22:33:22 +1100 as excerpted:
>
>> On Sun, Mar 13 2016, Qu Wenruo wrote:
>>
>>> BTW, I am always interested in, why de-duplication can be shorted as
>>> 'dedupe'.
>
>>> I didn't see any 'e' in the
NeilBrown posted on Sun, 13 Mar 2016 22:33:22 +1100 as excerpted:
> On Sun, Mar 13 2016, Qu Wenruo wrote:
>
>> BTW, I am always interested in, why de-duplication can be shorted as
>> 'dedupe'.
>> I didn't see any 'e' in the whole word "DUPlication".
>> Or it's an abbreviation of "DUPlicatE" inst
On Sun, Mar 13 2016, Qu Wenruo wrote:
> Qu Wenruo wrote on 2016/03/12 16:16 +0800:
>>
>>
>> On 03/11/2016 07:43 PM, David Sterba wrote:
>>> On Thu, Mar 10, 2016 at 08:57:12AM +0800, Qu Wenruo wrote:
> The ioctl FIDEDUPERANGE and the tool duperemove both use "dupe".
> It would be nice if we
Qu Wenruo wrote on 2016/03/12 16:16 +0800:
On 03/11/2016 07:43 PM, David Sterba wrote:
On Thu, Mar 10, 2016 at 08:57:12AM +0800, Qu Wenruo wrote:
The ioctl FIDEDUPERANGE and the tool duperemove both use "dupe".
It would be nice if we could be consistent and all use the same
abbreviation.
On 03/11/2016 07:43 PM, David Sterba wrote:
On Thu, Mar 10, 2016 at 08:57:12AM +0800, Qu Wenruo wrote:
The ioctl FIDEDUPERANGE and the tool duperemove both use "dupe".
It would be nice if we could be consistent and all use the same
abbreviation.
Yes, current kernel VFS level offline dedup us
On Thu, Mar 10, 2016 at 08:57:12AM +0800, Qu Wenruo wrote:
> > The ioctl FIDEDUPERANGE and the tool duperemove both use "dupe".
> > It would be nice if we could be consistent and all use the same
> > abbreviation.
>
> Yes, current kernel VFS level offline dedup uses the name "dedupe".
> But on the
NeilBrown wrote on 2016/03/10 08:27 +1100:
On Thu, Feb 18 2016, Qu Wenruo wrote:
+
+/*
+ * Dedup storage backend
+ * On disk is persist storage but overhead is large
+ * In memory is fast but will lose all its hash on umount
+ */
+#define BTRFS_DEDUP_BACKEND_INMEMORY 0
+#define BTRF
On Thu, Feb 18 2016, Qu Wenruo wrote:
> +
> +/*
> + * Dedup storage backend
> + * On disk is persist storage but overhead is large
> + * In memory is fast but will lose all its hash on umount
> + */
> +#define BTRFS_DEDUP_BACKEND_INMEMORY 0
> +#define BTRFS_DEDUP_BACKEND_ONDISK 1
