My system mounts the wrong btrfs partition, from the wrong disk!

My system mounts the wrong btrfs partition, from the wrong disk!

[Niccolò Belli]

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

Re: My system mounts the wrong btrfs partition, from the wrong disk!

[Roman Mamedov]

On Fri, 25 Nov 2016 12:05:57 +0100
Niccolò Belli <darkbasic@linuxsystems.it> wrote:

> 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.

https://btrfs.wiki.kernel.org/index.php/Gotchas#Block-level_copies_of_devices

"don't make copies with dd."

-- 
With respect,
Roman

Re: My system mounts the wrong btrfs partition, from the wrong disk!

[Chris Murphy]

On Fri, Nov 25, 2016 at 4:17 AM, Roman Mamedov <rm@romanrm.net> wrote:
> On Fri, 25 Nov 2016 12:05:57 +0100
> Niccolò Belli <darkbasic@linuxsystems.it> wrote:
>
>> 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.
>
> https://btrfs.wiki.kernel.org/index.php/Gotchas#Block-level_copies_of_devices
>
> "don't make copies with dd."

Yeah.

In the user's defense, it's way overdue for the kernel to refuse to
mount without some override flag like XFS does. This behavior is just
plain user hostile right now, and Btrfs gets an extra ding because
it's supposed to be better: easier to admin and have better data
integrity. Basically this is Btrfs eating at least one, possibly both,
file systems at the same time without warning, and it's not good
enough to warn in the wiki.


-- 
Chris Murphy

Re: My system mounts the wrong btrfs partition, from the wrong disk!

[Goffredo Baroncelli]

On 2016-11-26 00:56, Chris Murphy wrote:
> On Fri, Nov 25, 2016 at 4:17 AM, Roman Mamedov <rm@romanrm.net> wrote:
>> On Fri, 25 Nov 2016 12:05:57 +0100
>> Niccolò Belli <darkbasic@linuxsystems.it> wrote:
>>
>>> 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.
>>
>> https://btrfs.wiki.kernel.org/index.php/Gotchas#Block-level_copies_of_devices
>>
>> "don't make copies with dd."
> 
> Yeah.
> 
> In the user's defense, it's way overdue for the kernel to refuse to
> mount without some override flag like XFS does. This behavior is just
> plain user hostile right now, and Btrfs gets an extra ding because
> it's supposed to be better: easier to admin and have better data
> integrity. Basically this is Btrfs eating at least one, possibly both,
> file systems at the same time without warning, and it's not good
> enough to warn in the wiki.
> 


When I read these "incidents" on the ML, I still think that the actual BTRFS way to handling the devices discovery is overcomplicated and not reliable: currently udev push back the device in the kernel which manages an own list of btrfs devices. Then the mount command suggests the kernel to mount a filesystem on the basis of the UUID. In case of problem nor udev nor mount are capable to print any useful message and/or suggestion. Even in case of UUID conflicts (which could be very simple to handle) this system is unreliable.

In the past I developed a mount.btrfs helper which took care of devices discovery and also of these checks; also it could be a place where develop the handling of incomplete multi-disks filesystem....

I hope that sooner or later someone rethink about that.

http://www.spinics.net/lists/linux-btrfs/msg39706.html


BR
G.Baroncelli


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5