Hi Glenn,
At 12/29/2016 06:20 PM, Glenn Washburn wrote:
Hi Qu,
Thanks for your response. I've attached the send file as you have
requested. The "-2" one is created from the same script modified to
create a snapshot of C called C.snap instead of setting C to readonly,
and sending C.snap instead of C. The second version is to mirror what
you seemed to do in your reply. Still no reflinking. I've included
the original script and log again, which was modified to show more
verbose logging on the receive.
Confirmed it's kernel bug.
Send stream doesn't contain the clone operation.
So it's kernel send to blame.
As I was using btrgs-progs v4.4, I've compiled v4.9 to get the nice
--dump option for receive (which you seem to have added, kudos!). The
output of the dump option is in the *.recv-dump.log files. However, I
see no clone command in the output.
Keep in mind that I'm running Ubuntu kernel 4.4.0-53-generic, which I
believe to be mostly v4.4.30 with a few patches. Any ideas when send
started using "clone" in the kernel?
Not pretty sure about from which exact kernel version send can detect
reflink.
AFAIC I sent an RFC patch to disable reflink detection in send in July
2016, and it just got rejected.
So I assume at least v4.6 kernel works.
Thanks,
Qu
Thanks,
Glenn
On Thu, 29 Dec 2016 13:55:46 +0800
Qu Wenruo <quwen...@cn.fujitsu.com> wrote:
Hi,
I tried just what you did, and use "btrfs receive --dump" to exam the
send stream.
And things works quite well:
$ sudo mount /dev/sda6 /mnt/btrfs/
$ sudo btrfs subvolume create /mnt/btrfs/subv1
$ sudo xfs_io -f -c "pwrite 0 2M" /mnt/btrfs/subv1/file1
$ sudo xfs_io -f -c "reflink /mnt/btrfs/subv1/file1 0 0 2M"
/mnt/btrfs/subv1/file1.ref
$ sudo btrfs subv snap -r /mnt/btrfs/subv1/ /mnt/btrfs/ro_snap
$ sudo btrfs send /mnt/btrfs/ro_snap/ > /tmp/output
$ sudo btrfs receive --dump < /tmp/output
And the output shows like this:
subvol ./ro_snap
uuid=e788bb6e-8ec6-dd47-a452-e26196d22699 transid=9
chown ./ro_snap/ gid=0 uid=0
chmod ./ro_snap/ mode=755
utimes ./ro_snap/
atime=2016-12-29T13:46:00+0800 mtime=2016-12-29T13:46:50+0800
ctime=2016-12-29T13:46:50+0800
mkfile ./ro_snap/o257-8-0rename ./ro_snap/o257-8-0
dest=./ro_snap/file1
utimes ./ro_snap/
atime=2016-12-29T13:46:00+0800 mtime=2016-12-29T13:46:50+0800
ctime=2016-12-29T13:46:50+0800
write ./ro_snap/file1 offset=0 len=49152
write ./ro_snap/file1 offset=49152 len=49152
<snip normal write for file1>
write ./ro_snap/file1 offset=2064384
len=32768 truncate ./ro_snap/file1 size=2097152
chown ./ro_snap/file1 gid=0 uid=0
chmod ./ro_snap/file1 mode=600
utimes ./ro_snap/file1
atime=2016-12-29T13:46:24+0800 mtime=2016-12-29T13:46:24+0800
ctime=2016-12-29T13:46:24+0800
mkfile ./ro_snap/o258-8-0rename ./ro_snap/o258-8-0
dest=./ro_snap/file1.ref
utimes ./ro_snap/
atime=2016-12-29T13:46:00+0800 mtime=2016-12-29T13:46:50+0800
ctime=2016-12-29T13:46:50+0800
clone ./ro_snap/file1.ref offset=0 len=2097152
from=./ro_snap/file1 clone_offset=0
^^^ Here is the clone operation
truncate ./ro_snap/file1.ref size=2097152
chown ./ro_snap/file1.ref gid=0 uid=0
chmod ./ro_snap/file1.ref mode=600
utimes ./ro_snap/file1.ref
atime=2016-12-29T13:46:50+0800 mtime=2016-12-29T13:47:07+0800
ctime=2016-12-29T13:47:07+0800
And in fact, btrfs send can even handle reflink to parent subvolume.
(Although this behavior can be deadly for heavily reflinked files)
So, would you please upload the send stream for us to check?
Thanks,
Qu
At 12/29/2016 10:44 AM, Glenn Washburn wrote:
I'm having a hard time getting btrfs receive to create reflinked
files and have a trivial example that I believe *should* work but
doesn't. I've attached a script that I used to perform this test,
so others can try to reproduce. The text file is the output of the
shell script except the last command, which is a tool I wrote to
print the extent info from FIEMAP. "btrfs fi du" would work just
as well, but I'm on Ubuntu 16.04, whose btrfs progs doesn't have
that command yet. I've also tested on Ubuntu 16.10 with similar
results, except that "btrfs fi du" is on that version and confirms
what my tool displays.
So, can send not do what I'm trying to get it to do? If it can now,
when did that feature get introduced (must have been after kernel
4.8)? I'm very surprised that this feature wouldn't have already
been done and if not that no one seems to be complaining about it.
I've done a decent amount of searching on this and have come up with
nothing. Any help would be greatly appreciated.
Thanks,
Glenn
--
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
