Btrfs devel - Jul 2012 - 3.5.0-rc6: btrfs and LVM snapshots -> wrong devicename in /proc/mounts

Hi,

using btrfs with LVM snapshots seems to be confusing /proc/mounts
After mounting a snapshot of an original filesystem, the devicename of the
original filesystem is overwritten with that of the snapshot in /proc/mounts.

Steps to reproduce:

arnd@kallisto:/mnt$ sudo mount /dev/vg0/original /mnt/original
[  107.041432] device fsid 5c3e8ca2-da56-4ade-9fef-103a6a8a70c2 devid 1 transid
4 /dev/mapper/vg0-original
[  107.044691] btrfs: no dev_stats entry found for device
/dev/mapper/vg0-original (devid 1) (OK on first mount after mkfs)

arnd@kallisto:/mnt$ cat /proc/mounts  | grep /mnt
/dev/mapper/vg0-original /mnt/original btrfs rw,relatime,ssd,space_cache 0 0

arnd@kallisto:/mnt$ sudo lvcreate -L 10M --snap --name snapshot
/dev/vg0/original
arnd@kallisto:/mnt$ sudo mount /dev/vg0/testsnap /mnt/testsnap
[  215.432281] device fsid 5c3e8ca2-da56-4ade-9fef-103a6a8a70c2 devid 1 transid
4 /dev/mapper/vg0-testsnap

arnd@kallisto:/mnt$ cat /proc/mounts  | grep /mnt
/dev/mapper/vg0-testsnap /mnt/original btrfs rw,relatime,ssd,space_cache 0 0
/dev/mapper/vg0-testsnap /mnt/testsnap btrfs rw,relatime,ssd,space_cache 0 0

arnd@kallisto:/mnt$ sudo umount /dev/vg0/testsnap
arnd@kallisto:/mnt$ cat /proc/mounts | grep /mnt
/dev/mapper/vg0-testsnap /mnt/original btrfs rw,relatime,ssd,space_cache 0 0


Best regards,
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Mon, Jul 9, 2012 at 4:22 PM, Arnd Hannemann <arnd@arndnet.de>
wrote:
> Hi,
>
> using btrfs with LVM snapshots seems to be confusing /proc/mounts
> After mounting a snapshot of an original filesystem, the devicename of the
> original filesystem is overwritten with that of the snapshot in
/proc/mounts.
If the lvm snapshot is visible to btrfs (i.e., btrfs dev scan), it
will appear as another device which belongs to the original filesystem
with a duplicate devid.  This might result in bad things happening, or
possibly just hilarity.

You have a backup that isn''t just an lvm snapshot, right?
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi,

Am 10.07.2012 05:30, schrieb Christian Robert:
> I agree with you, but you should never mount a snapshot of a btrfs
filesystem at the same time the original is,
> because both the original and the snapshot had same "device fsid
5c3e8ca2-da56-4ade-9fef-103a6a8a70c2"
> 
> the kernel will tkink twice and fold back to the same device.
If that is correct the bug is that the kernel lets me mount the same device fsid
on different devices twice.
> 
> btrsf does not behave like other filesystems, you can''t snapshot a
btrfs filesystem
> and hope to mount the snapshot somewhere else.
> snapsoot also duplicate lots of things internally that have no sence in a
snapshot (like raid level, single or multiple devies ...)
I see. However, I expect a "simple" btrfs to just work or fail
gracefully.

Best regards,
Arnd

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Am 10.07.2012 00:49, schrieb cwillu:
> On Mon, Jul 9, 2012 at 4:22 PM, Arnd Hannemann <arnd@arndnet.de>
wrote:
>> Hi,
>>
>> using btrfs with LVM snapshots seems to be confusing /proc/mounts
>> After mounting a snapshot of an original filesystem, the devicename of
the
>> original filesystem is overwritten with that of the snapshot in
/proc/mounts.
> 
> If the lvm snapshot is visible to btrfs (i.e., btrfs dev scan), it
> will appear as another device which belongs to the original filesystem
> with a duplicate devid.  This might result in bad things happening, or
> possibly just hilarity.
You are right the same bug seems to get triggered on "btrfs dev scan":

arnd@kallisto:/mnt$ sudo grep /mnt /proc/mounts
/dev/mapper/vg0-original /mnt/original btrfs rw,relatime,ssd,space_cache 0 0
arnd@kallisto:/mnt$ sudo btrfs dev scan
Scanning for Btrfs filesystems
failed to read /dev/sr0
ERROR: unable to scan the device ''/dev/dm-4'' - Device or
resource busy
ERROR: unable to scan the device ''/dev/dm-17'' - Device or
resource busy

arnd@kallisto:/mnt$ sudo grep /mnt /proc/mounts
/dev/dm-16 /mnt/original btrfs rw,relatime,ssd,space_cache 0 0

arnd@kallisto:/mnt$ sudo dmsetup info /dev/dm-16
Name:              vg0-testsnap
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        0
Event number:      0
Major, minor:      253, 16
Number of targets: 1
UUID: LVM-pUa0TTDg9Y1dII6a6WwcUanE0ai4AVXqpS7sNnWEGZOnww76lrMaZzIEB38rug9

> You have a backup that isn''t just an lvm snapshot, right?
Now I will.

Best regards
Arnd




--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On 07/10/2012 10:52 AM, Arnd Hannemann wrote:
> Hi,
> 
> Am 10.07.2012 05:30, schrieb Christian Robert:
>> I agree with you, but you should never mount a snapshot of a btrfs
filesystem at the same time the original is,
>> because both the original and the snapshot had same "device fsid
5c3e8ca2-da56-4ade-9fef-103a6a8a70c2"
I think that the kernel should be smarter in this regard.

At kernel level, as golden rule it should be not possible to add a
duplicate fsid if the previous one is mounted. "btrfs dev scan" MUST
return an error in this case. This in any case is an error.

Today it seems that if a device with the same fsid is already
registered, the new one overwrites the old one (or almost the name is
overwritten). This could be acceptable if the filesystem is unmounted. I
think that it is a serious error otherwise.
>>
>> the kernel will tkink twice and fold back to the same device.
> 
> If that is correct the bug is that the kernel lets me mount the same device
fsid on different devices twice.
> 
>>
>> btrsf does not behave like other filesystems, you can''t
snapshot a btrfs filesystem
>> and hope to mount the snapshot somewhere else.
> 
>> snapsoot also duplicate lots of things internally that have no sence in
a snapshot (like raid level, single or multiple devies ...)
> 
> I see. However, I expect a "simple" btrfs to just work or fail
gracefully.
> 
> Best regards,
> Arnd
> 
> --
> To unsubscribe from this list: send the line "unsubscribe
linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> .
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi Arnd,

I am trying to reproduce this bug. Which kernel version are you using ?

BR
G.Baroncelli

On 07/10/2012 07:55 PM, Goffredo Baroncelli wrote:
> On 07/10/2012 10:52 AM, Arnd Hannemann wrote:
>> Hi,
>>
>> Am 10.07.2012 05:30, schrieb Christian Robert:
>>> I agree with you, but you should never mount a snapshot of a btrfs
filesystem at the same time the original is,
>>> because both the original and the snapshot had same "device
fsid 5c3e8ca2-da56-4ade-9fef-103a6a8a70c2"
> 
> I think that the kernel should be smarter in this regard.
> 
> At kernel level, as golden rule it should be not possible to add a
> duplicate fsid if the previous one is mounted. "btrfs dev scan"
MUST
> return an error in this case. This in any case is an error.
> 
> Today it seems that if a device with the same fsid is already
> registered, the new one overwrites the old one (or almost the name is
> overwritten). This could be acceptable if the filesystem is unmounted. I
> think that it is a serious error otherwise.
> 
>>>
>>> the kernel will tkink twice and fold back to the same device.
>>
>> If that is correct the bug is that the kernel lets me mount the same
device fsid on different devices twice.
>>
>>>
>>> btrsf does not behave like other filesystems, you can''t
snapshot a btrfs filesystem
>>> and hope to mount the snapshot somewhere else.
>>
>>> snapsoot also duplicate lots of things internally that have no
sence in a snapshot (like raid level, single or multiple devies ...)
>>
>> I see. However, I expect a "simple" btrfs to just work or
fail gracefully.
>>
>> Best regards,
>> Arnd
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> .
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe
linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> .
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi Goffredo,

Am 10.07.2012 20:42, schrieb Goffredo Baroncelli:
> Hi Arnd,
> 
> I am trying to reproduce this bug. Which kernel version are you using ?
I''m using linus'' vanilla tree from Sunday which is 3.5.0-rc6
plus some unsuspicious commits.

Best regards
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html