I'm experiencing a very weird Btrfs "send" issue with file reflinks, and after so many trials, I found the details: First, I created a subvolume called "1":

btrfs subvolume create 1

and dd a file in it:

dd if=/dev/urandom of=1/a bs=64 count=3110017

Now make a read-only snapshot by sudo btrfs subvolume snapshot -r 1 1_ro0, and then do cp --reflink=always 1/a 1/b, make a ro snapshot again: sudo btrfs subvolume snapshot -r 1 1_ro1. Now count the data size from "btrfs send":

sudo btrfs send -p 1_ro0 1_ro1 | wc -c

It outputs 64864765, which is about 61.9MiB. This's so abnormal - I just copied it using reflink, I don't know why "btrfs send" outputs so much data. However, if the count above in dd is replaced with 3110016 (3110017-1), then did the routines above again, with wc -c on "btrfs send", you can get 604 (604 B), only 604 bytes, and this is what I expect. I also made a bash script to do those two tests:

#!/bin/bash

btrfs subvolume create 1

rm -rf 1/*
dd if=/dev/urandom of=1/a bs=64 count=3110017
sudo btrfs subvolume snapshot -r 1 1_ro0
cp --reflink=always 1/a 1/b
sudo btrfs subvolume snapshot -r 1 1_ro1
sudo btrfs send -p 1_ro0 1_ro1 | wc -c
sudo btrfs subvolume delete 1_ro0 1_ro1


rm -rf 1/*
dd if=/dev/urandom of=1/a bs=64 count=3110016
sudo btrfs subvolume snapshot -r 1 1_ro0
cp --reflink=always 1/a 1/b
sudo btrfs subvolume snapshot -r 1 1_ro1
sudo btrfs send -p 1_ro0 1_ro1 | wc -c
sudo btrfs subvolume delete 1_ro0 1_ro1

rm -r 1

If replace wc -c with btrfs receive --dump to inspect the "btrfs send" output data, with dd 3110016 value it will output a few "clone" entries like this:

clone           ./1_ro1/b                       offset=0 len=134217728 from=./1_ro1/a clone_offset=0
clone           ./1_ro1/b                       offset=134217728 len=64823296 from=./1_ro1/a clone_offset=134217728
...

But with dd value 3110017, it outputs:

write           ./1_ro1/b                       offset=197918720 len=49152
write           ./1_ro1/b                       offset=197967872 len=49152
write           ./1_ro1/b                       offset=198017024 len=49152
write           ./1_ro1/b                       offset=198066176 len=49152
write           ./1_ro1/b                       offset=198115328 len=49152
write           ./1_ro1/b                       offset=198164480 len=49152
... (so many more)

which contains a bunch of "write" entries. I also searched and noticed this site: https://www.spinics.net/lists/linux-btrfs/msg105951.html , and it's like talking about file holes, but in my case it obviously can't be. This is so weird and I don't know what I'm missing. My btrfs-progs version is 5.18.1-1 and the mount options from /proc/mount: rw,relatime,space_cache=v2,subvolid=5,subvol=/ Thanks!

I have a folder root1 on disk partition sda1 which contain reflink/mnt/sda1/root1/a->/mnt/sda1/root1/raw/a I have another folder root1 on disk partition sdb1, that has reflink /mnt/sdb1/root1/a->/mnt/sdb1/backup/raw/a. sda1 and sdb1 has same file system. It can either both be XFS or both be btrfs If I do copy -r --reflink=always /mnt/sda1/root1 /mnt/sdb1/root1.What will happen to my data? - case 1: the /mnt/sda1/root1/a and /mnt/sdb1/root1/a are exactly the same. - case 2: the /mnt/sda1/root1/a and /mnt/sdb1/root1/a are different in some blocks. but /mnt/sda1/root1/raw/a and /mnt/sdb1//backup/raw/a are the same. - case 3: all 4 a are different but most of the blocks are the same. Is the copy smart enough to maintain the block sharing on the /sdb1?

btrfs supports reflinks, XFS supports reflinks [(since 2017 I think?)](https://blogs.oracle.com/linux/xfs-data-block-sharing-reflink#:~:text=Three%20years%20ago%2C%20I%20introduced,efficient%20use%20of%20storage%20hardware.) . Are there any other filesystems that support it?

truncate -s 1G test.file;
cp --reflink=always test.file ref.test.file;

I try to create a snapshot copy of a directory recursively, but it returns errors for every single file if the filesystem (custom shfs) does not support reflink copies: # cp -a --reflink=always /mnt/user/libvirt /mnt/user/libvirt_copy cp: failed to clone '/mnt/user/libvirt_copy/libvirt/libvirt.img' from '/mnt/user/libvirt/libvirt.img': Operation not supported cp: failed to clone '/mnt/user/libvirt_copy/libvirt/test.txt' from '/mnt/user/libvirt/test.txt': Operation not supported ... As it seems to be impossible to stop cp on the first error (?), which means useless looping through probably thousands of files, I instead like to pre-check if the filesystem supports reflinks. One idea is to search for a single file and do a testcopy: if ! find /mnt/user/libvirt -type f -print -quit | xargs -I {} sh -c 'dst_path=$(dirname $(echo {} | sed "s#^/mnt/user/libvirt#/mnt/user/libvirt_copy#")); mkdir -vp $dst_path && cp -a --reflink=always {} "$dst_path"'; then echo "Error: Filesystem does not support reflink" exit fi But this leaves the dir and an empty file which needs to be cleaned up afterwards: # find /mnt/user/libvirt_copy/ /mnt/user/libvirt_copy/ /mnt/user/libvirt_copy/libvirt.img # ls -lah /mnt/user/libvirt_copy/libvirt.img -rw------- 1 root root 0 Nov 1 08:58 /mnt/user/libvirt_copy/libvirt.img Isn't there an better way? Or maybe there is a solution to stop cp on the first error?

Btrfs support Copy-On-Write. I tried to use that feature to clone a directory: cp -R --reflink=always foo_directory foo_directory.mirror I expected the command to finish almost instantly (like a btrfs subvolume snapshot), but the cp command seems to perform a slow, standard copy. According to the man page, I would expected --reflink=always to enforce Copy-On-Write: > When --reflink[=always] is specified, perform a lightweight copy, where the data blocks are copied only when modified. If this is not possible the copy fails, or if --reflink=auto is specified, fall back to a standard copy. **Questions:** - Do you know why --reflink=always doesn't work? - What options (or other commands) should I use instead?

What's the difference between --link and --reflink=always? I use the following command as an mv substitute, and I am wondering if using --reflink is a better choice.

command gcp -r --link --archive --verbose "${opts[@]}" "$@"
# delete the sources manually

It's clear, with cp --reflink foo bar I can copy a file on btrfs without wasting space. But how can I detect that the two files (foo and bar here) are using the same "space unit"? If they were hardlinks, I would use [ foo -ef bar ] for comparing or stat -c%i foo to get a unique id (inode in this case). Are there similar commands for btrfs reflinked files? I want to apply this on a 300G volume which is virtually 6T in size due to deduplication, so I want to avoid checksumming...

I currently have a 4TB RAID 1 setup on a small, personal Linux server, which is formatted as XFS in LVM. I am interested in enabling the reflink feature of XFS, but I did not do so when I first created the filesystem (I used the defaults). Is there a way that I can toggle the reflink feature on, without having to backup and re-create the filesystem? And if not, can I expect that feature to be implemented in the future?

I have huge files {0..9}.bin which I want concatenate into out.bin. I don't need the original files afterwards. So I was wondering, if this is possible by only modifying the filesystem index without copying the file contents (see https://unix.stackexchange.com/q/80429/234981 for efficient copy solutions). On modern file systems (e.g. btrfs) cp --reflink=always exists. Fifos are on the file system level (at least btrfs send also tracks fifos), so they should have information about the actual data blocks used. Therefore, cp --reflink=always should be able to determine the extend numbers on disk and re-use them. So I was wondering, if it is possible to use mkfifo in combination with cp --reflink=always? **Update** Currently, it is not working:

for i in {1..9}; do dd if=/dev/urandom of="in$i.bin" bs=5M count=200; done;
mkfifo fifo
cat in* >fifo &
cp --reflink=always fifo out.bin

results in cp: failed to clone 'out.bin' from 'fifo': Invalid argument Probably, it never will, since FIFOs have no information about the storage origin bug instead are just dumb pipes.

I want to make a behaviour like btrfs send and btrfs receive, but on a per-file basis. As far as I see it, I can use cp -ax --reflink=always to make a "snapshot" of the file. Let's assume that two such "snapshots" on two different hard disks are exactly equal. How do I cp the diff (and only the diff) between two reflinked files like btrfs send -p would do it? Ideally, I would like to have a solution that works on any filesystem that is capable of making reflinks and not only on btrfs. Also ideally, I would like to run it without sudo. I know that I can look at the file extents with filefrag, but filefrag does not guarantee that the results are exact. I would rather copy some megabytes more than taking the risk of a corrupted file.

I was reading the [rmlint](http://rmlint.readthedocs.io/en/latest/index.html#) manual, and one of the duplicate handlers are clone and reflink: >· clone: btrfs only. Try to clone both files with the BTRFS_IOC_FILE_EXTENT_SAME ioctl(3p). This will physically delete duplicate extents. Needs at least kernel 4.2. > >· reflink: Try to reflink the duplicate file to the original. See also --reflink in man 1 cp. Fails if the filesystem does not support it. What exactly does this clone do, and how is it different from a reflink? What does the BTRFS_IOC_FILE_EXTENT_SAME ioctl do?