This is something pretty unbelievable, so I had to repeat it several times
before finding the courage to actually post it to the mailing list :)
After dozens of data loss I don't trust my btrfs partition that much, so I
make a backup copy with dd weekly. Yesterday I was going to do some
balancing and deduplication, but since the disk was full I had to remove
the content of a whole subvolume (16GB) to make some space available to the
tools (I had the backup made with dd on an external drive).
After the balance and deduplication I attached and mounted the external
drive with the backup and then I mounted the img file with the copy of the
partition. To my great wonder the subvolume in the backup which should have
had the files I deleted was empty! So I rebooted to a live usb and mounted
the backup again: my files were still there, phew! Then I mounted the
partition in the laptop's disk and I tried to copy the files from the
backup and it complained that they already existed! If I unmount both the
backup and the real disk and then I mount the real disk it's empty again as
it should.
These are the exact steps to reproduce it from the live usb:
# Opening the encrypted partition from the real disk and then mounting it
cryptsetup luksOpen /dev/sda5 cryptroot
mount -o noatime,compress=lzo,autodefrag /dev/mapper/cryptroot /real_disk
ls /real_disk/@Pictures --> empty (as it should)
# Mounting the external disk with the backup
mount /dev/sdb1 /external_disk
# Mounting the unencrypted backup from the external disk
mount /external_disk/backup.img /backup
ls /backup/@Pictures ---> empty (*it shouldn't!*)
umount /backup
umount /external_disk
cryptsetup luksClose cryptroot
# Mounting the external disk with the backup
mount /dev/sdb1 /external_disk
# Mounting the unencrypted backup from the external disk
mount /external_disk/backup.img /backup
ls /backup/@Pictures ---> 16GB of photos (as it should)
# Opening the encrypted partition from the real disk and then mounting it
cryptsetup luksOpen /dev/sda5 cryptroot
mount -o noatime,compress=lzo,autodefrag /dev/mapper/cryptroot /real_disk
ls /real_disk/@Pictures --> 16GB of photos (it *shouldn't!*)
I really don't know where the bug may lie, probably not even in btrfs but I
didn't know where to report it. I'm using Archlinux with kernel 4.8.10 and
the live is an Arch live usb with kernel 4.8 too.
Niccolò Belli
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html