On Thu, Mar 08, 2018 at 03:29:48PM +0000, Filipe Manana wrote: > On Wed, Mar 7, 2018 at 6:49 PM, Liu Bo <bo.li....@oracle.com> wrote: > > Hi, > > > > In the following steps[1], if <parent> on receiver side has got > > changed via 'btrfs property set', then after doing incremental > > updates, receiver gets a different snapshot from what sender has sent. > > > > The reason behind it is that there is no change about file 'foo' in > > the send stream, such that receiver simply creates a snapshot of > > <parent> on its side with nothing to apply from the send stream. > > > > A possible way to avoid this is to check rtransid and ctranid of > > <parent> on receiver side, but I'm not very sure whether the current > > behavior is made deliberately, does anyone have an idea? > > > > Thanks, > > > > -liubo > > > > [1]: > > $ btrfs sub create /mnt/send/sub > > $ touch /mnt/send/sub/foo > > $ btrfs sub snap -r /mnt/send/sub /mnt/send/parent > > > > # send parent out > > $ btrfs send /mnt/send/parent | btrfs receive /mnt/recv/ > > > > # change parent and file under it > > $ btrfs property set -t subvol /mnt/recv/parent ro false > > $ truncate -s 4096 /mnt/recv/parent/foo > > > > $ btrfs sub snap -r /mnt/send/sub /mnt/send/update > > $ btrfs send -p /mnt/send/parent /mnt/send/update | btrfs receive /mnt/recv > > > > $ ls -l /mnt/send/update > > total 0 > > -rw-r--r-- 1 root root 0 Mar 6 11:13 foo > > > > $ ls -l /mnt/recv/update > > total 0 > > -rw-r--r-- 1 root root 4096 Mar 6 11:14 foo > > Interesting. I wasn't aware of that and I'm surprised too, I wouldn't > expect that behaviour (and I must see the code to figure out why it > behaves like that).
The code about comparing rtransid and ctransid does exist in cmds-receive.c, but had been commented. Thanks, -liubo -- 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
