After subvolume send on btrfs the sent subvolume journal files have different contents than the original subvolume journal files. sha1sum {/snapshots/snapshot-2013-12-12T07.35.51N0007ff-sent,/mnt/snapshots/schur/root/snapshot-2013-12-12T07.35.51N0007ff}/var/log/journal/121d803e5e9a59f16ec21af30000000f/system@a5590d66040b4e6d98a8f07894937ab9-0000000000000001-0004e4523d76b700.journal 11b4a92dd4d72ef003e675a2a89afae4d337b46b /snapshots/snapshot-2013-12-12T07.35.51N0007ff-sent/var/log/journal/121d803e5e9a59f16ec21af30000000f/system@a5590d66040b4e6d98a8f07894937ab9-0000000000000001-0004e4523d76b700.journal 7eff13a4934c5353bf9a988943d148636f818fdc /mnt/snapshots/schur/root/snapshot-2013-12-12T07.35.51N0007ff/var/log/journal/121d803e5e9a59f16ec21af30000000f/system@a5590d66040b4e6d98a8f07894937ab9-0000000000000001-0004e4523d76b700.journal
Apparently the send needs to be incremental probably with some actual changes in journal files.
Journal files can be preallocated, this is not supported in current send stream format or code. Will be addressed in v2.
I think it was stated that file content semantics should be still honoured by sending 0-filled writes if I can recall correctly.
Yeah even tho we don't send the prealloc stuff across we will be sending 0's which means the sha's _should_ match. So the fact that they are not is a problem so it's definitely a bug. I'll try and figure out what is going on.
Just to note, I have also this issue with other files: jkarlson/.config/chromium/Default/Archived History jkarlson/.local/share/Trash/files/wheezy-x86_64.img jkarlson/.local/share/evolution/addressbook/system/log.0000000001 jkarlson/.local/storage/vm-images/wheezy-x86_32.img jkarlson/.local/storage/vm-images/wheezy-x86_64.img jkarlson/.local/storage/vm-images/windows-2008-server.img Everything has full CoW and autodefrag unless applications are doing something for me. There is also hourly snapshotting, which may hinder autodefrag. qemu-kvm access mode is if=virtio,cache=unsafe,aio=native, all images are created using truncate, holepunch has been applied sometimes using fstrim/loop though probably is not necessary condition for this .local/share/evolution/addressbook/system/log.0000000001: Berkeley DB (Log, version 16, native byte-order) .config/chromium/Default/Archived History: SQLite 3.x database
#60673 also mentions firefox/chromium explicitly, so it may be related in the scope of sqlite3.
I guess this could be put to needinfo or fixed, as I need to reproduce this again and then check with https://git.kernel.org/cgit/linux/kernel/git/josef/btrfs-next.git/commit/?id=6b4843d59fde1893d2aac38cab32fa5cfc6179c8
Discussed this on the IRC with fdmanana and the fix is not relevant to this problem. Also I am able to reproduce again.
This is a semi-automated bugzilla cleanup, report is against an old kernel version. If the problem still happens, please open a new bug. Thanks.