btrfs and deduplication

[Markus Raps]

Hi there,

currently iam trying to get deduplication working in debian/btrfs

#so i created a btrfs filesystem

mkfs.btrfs /dev/vdb1
mkdir /mnt/btrfs
mount /dev/vdb1 /mnt/btrfs

# create some random file
dd if=/dev/urandom of=/mnt/btrfs/img bs=1M count=1024
for i in {1..30}; do cp /mnt/btrfs/img /mnt/btrfs/img$i; done

# dedup this stuff
jdupes -S -B -r /mnt/btrfs/
Examining 31 files, 1 dirs (in 1 specified)
Deduplication done (30 files processed)

raps-debian btrfs # btrfs fi df /mnt/btrfs/
Data, single: total=31.50GiB, used=30.96GiB
System, DUP: total=32.00MiB, used=16.00KiB
Metadata, DUP: total=222.94MiB, used=33.69MiB
GlobalReserve, single: total=33.56MiB, used=0.00B

raps-debian btrfs # btrfs fi usage /mnt/btrfs/
Overall:
Device size: 32.00GiB
Device allocated: 32.00GiB
Device unallocated: 1.04MiB
Device missing: 0.00B
Used: 31.03GiB
Free (estimated): 549.41MiB (min: 549.41MiB)
Data ratio: 1.00
Metadata ratio: 2.00
Global reserve: 33.56MiB (used: 0.00B)

Data,single: Size:31.50GiB, Used:30.96GiB
/dev/vdb1 31.50GiB

Metadata,DUP: Size:222.94MiB, Used:33.69MiB
/dev/vdb1 445.88MiB

System,DUP: Size:32.00MiB, Used:16.00KiB
/dev/vdb1 64.00MiB

Unallocated:
/dev/vdb1 1.04MiB
raps-debian btrfs #



hm ... hasn't worked.
wrong tool ? did i missed something
or have i completely misunderstood deduplication?


Greetings
Markus

[Anders Andersson]

I can not answer this, but as a long time user of btrfs who has never
tried deduplication I got curious, so I tried to recreate your result
on my debian testing workstation, and for me it worked. Here is the
log of exactly how I created the filesystem, and the output from btrfs
fi usage before and after running jdupes. As you can see from the
usage after deduplication, both the allocated and used space has
decreased to what would be expected.

Perhaps your kernel is too old? It is possible that you are being hit
by the issue described here:
https://btrfs.wiki.kernel.org/index.php/Changelog#By_feature

"The range for out-of-band deduplication implemented by the
EXTENT_SAME ioctl will split the range into 16MiB chunks. Up to now
this was the overall limit and effectively only the first 16MiB was
deduplicated."

I can't say I understand much about it, but it was fixed in kernel
4.18 which happens to be what I use.



# btrfs --version
btrfs-progs v4.17
# uname -a
Linux spacelab 4.18.0-1-amd64 #1 SMP Debian 4.18.6-1 (2018-09-06)
x86_64 GNU/Linux
# lvcreate spacelab -n dedup -L 100G
# mkfs.btrfs /dev/spacelab/dedup
# mount /dev/spacelab/dedup /mnt/
# dd if=/dev/urandom of=/mnt/img bs=1M count=1024
# for i in {1..30}; do cp /mnt/img /mnt/img$i;done
# btrfs fi usage /mnt
Overall:
Device size: 100.00GiB
Device allocated: 33.02GiB
Device unallocated: 66.98GiB
Device missing: 0.00B
Used: 31.04GiB
Free (estimated): 67.98GiB (min: 67.98GiB)
Data ratio: 1.00
Metadata ratio: 1.00
Global reserve: 33.23MiB (used: 0.00B)

Data,single: Size:32.01GiB, Used:31.01GiB
/dev/mapper/spacelab-dedup 32.01GiB

Metadata,single: Size:1.01GiB, Used:33.36MiB
/dev/mapper/spacelab-dedup 1.01GiB

System,single: Size:4.00MiB, Used:16.00KiB
/dev/mapper/spacelab-dedup 4.00MiB

Unallocated:
/dev/mapper/spacelab-dedup 66.98GiB
# jdupes -S -B -r /mnt
Scanning: 31 files, 1 items (in 1 specified)

Deduplication done (30 files processed)

# btrfs fi usage /mnt
Overall:
Device size: 100.00GiB
Device allocated: 2.02GiB
Device unallocated: 97.98GiB
Device missing: 0.00B
Used: 1.00GiB
Free (estimated): 97.99GiB (min: 97.99GiB)
Data ratio: 1.00
Metadata ratio: 1.00
Global reserve: 16.00MiB (used: 0.00B)

Data,single: Size:1.01GiB, Used:1.00GiB
/dev/mapper/spacelab-dedup 1.01GiB

Metadata,single: Size:1.01GiB, Used:1.38MiB
/dev/mapper/spacelab-dedup 1.01GiB

System,single: Size:4.00MiB, Used:16.00KiB
/dev/mapper/spacelab-dedup 4.00MiB

Unallocated:
/dev/mapper/spacelab-dedup 97.98GiB

[Markus Raps]

just updated the kernel to 4.18
now it works

thank you



--
Mit freundlichen Grüßen / best regards
Markus Raps