Skip to content
  • Filipe Manana's avatar
    Btrfs: send, fix issuing write op when processing hole in no data mode · d4dfc0f4
    Filipe Manana authored
    
    
    When doing an incremental send of a filesystem with the no-holes feature
    enabled, we end up issuing a write operation when using the no data mode
    send flag, instead of issuing an update extent operation. Fix this by
    issuing the update extent operation instead.
    
    Trivial reproducer:
    
      $ mkfs.btrfs -f -O no-holes /dev/sdc
      $ mkfs.btrfs -f /dev/sdd
      $ mount /dev/sdc /mnt/sdc
      $ mount /dev/sdd /mnt/sdd
    
      $ xfs_io -f -c "pwrite -S 0xab 0 32K" /mnt/sdc/foobar
      $ btrfs subvolume snapshot -r /mnt/sdc /mnt/sdc/snap1
    
      $ xfs_io -c "fpunch 8K 8K" /mnt/sdc/foobar
      $ btrfs subvolume snapshot -r /mnt/sdc /mnt/sdc/snap2
    
      $ btrfs send /mnt/sdc/snap1 | btrfs receive /mnt/sdd
      $ btrfs send --no-data -p /mnt/sdc/snap1 /mnt/sdc/snap2 \
           | btrfs receive -vv /mnt/sdd
    
    Before this change the output of the second receive command is:
    
      receiving snapshot snap2 uuid=f6922049-8c22-e544-9ff9-fc6755918447...
      utimes
      write foobar, offset 8192, len 8192
      utimes foobar
      BTRFS_IOC_SET_RECEIVED_SUBVOL uuid=f6922049-8c22-e544-9ff9-...
    
    After this change it is:
    
      receiving snapshot snap2 uuid=564d36a3-ebc8-7343-aec9-bf6fda278e64...
      utimes
      update_extent foobar: offset=8192, len=8192
      utimes foobar
      BTRFS_IOC_SET_RECEIVED_SUBVOL uuid=564d36a3-ebc8-7343-aec9-bf6fda278e64...
    
    Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
    Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
    d4dfc0f4