All of lore.kernel.org
 help / color / mirror / Atom feed
From: Goffredo Baroncelli <kreijack@inwind.it>
To: MegaBrutal <megabrutal@gmail.com>,
	linux-btrfs <linux-btrfs@vger.kernel.org>
Cc: Robert White <rwhite@pobox.com>
Subject: Re: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots
Date: Tue, 02 Dec 2014 08:50:26 +0100	[thread overview]
Message-ID: <547D6F42.9000009@inwind.it> (raw)
In-Reply-To: <CAE8gLhkxgi8nTab0rzmLNzhsek_v2zs6RxPDL9GU_EAen9+kvA@mail.gmail.com>

On 12/02/2014 01:15 AM, MegaBrutal wrote:
> 2014-12-02 0:24 GMT+01:00 Robert White <rwhite@pobox.com>:
>> On 12/01/2014 02:10 PM, MegaBrutal wrote:
>>>
>>> Since having duplicate UUIDs on devices is not a problem for me since
>>> I can tell them apart by LVM names, the discussion is of little
>>> relevance to my use case. Of course it's interesting and I like to
>>> read it along, it is not about the actual problem at hand.
>>>
>>
>> Which is why you use the device= mount option, which would take LVM names
>> and which was repeatedly discussed as solving this very problem.
>>
>> Once you decide to duplicate the UUIDs with LVM snapshots you take up the
>> burden of disambiguating your storage.
>>
>> Which is part of why re-reading was suggested as this was covered in some
>> depth and _is_ _exactly_ about the problem at hand.
> 
> Nope.
> 
> root@reproduce-1391429:~# cat /proc/cmdline
> BOOT_IMAGE=/vmlinuz-3.18.0-031800rc5-generic
> root=/dev/mapper/vg-rootlv ro
> rootflags=device=/dev/mapper/vg-rootlv,subvol=@
> 
> Observe, device= mount option is added.

device= options is needed only in a btrfs multi-volume scenario.
If you have only one disk, this is not needed

> 
> 
> root@reproduce-1391429:~# ./reproduce-1391429.sh
> #!/bin/sh -v
> lvs
>   LV     VG   Attr      LSize   Pool Origin Data%  Move Log Copy%  Convert
>   rootlv vg   -wi-ao---   1.00g
>   swap0  vg   -wi-ao--- 256.00m
> 
> grub-probe --target=device /
> /dev/mapper/vg-rootlv
> 
> grep " / " /proc/mounts
> rootfs / rootfs rw 0 0
> /dev/dm-1 / btrfs rw,relatime,space_cache 0 0
> 
> lvcreate --snapshot --size=128M --name z vg/rootlv
>   Logical volume "z" created
> 
> lvs
>   LV     VG   Attr      LSize   Pool Origin Data%  Move Log Copy%  Convert
>   rootlv vg   owi-aos--   1.00g
>   swap0  vg   -wi-ao--- 256.00m
>   z      vg   swi-a-s-- 128.00m      rootlv   0.11
> 
> ls -l /dev/vg/
> total 0
> lrwxrwxrwx 1 root root 7 Dec  2 00:12 rootlv -> ../dm-1
> lrwxrwxrwx 1 root root 7 Dec  2 00:12 swap0 -> ../dm-0
> lrwxrwxrwx 1 root root 7 Dec  2 00:12 z -> ../dm-2
> 
> grub-probe --target=device /
> /dev/mapper/vg-z
>
> grep " / " /proc/mounts
> rootfs / rootfs rw 0 0
> /dev/dm-2 / btrfs rw,relatime,space_cache 0 0

What /proc/self/mountinfo contains ?

And more important question: it is only the value
returned by /proc/mount wrongly or also the filesystem
content is affected ?

> 
> lvremove --force vg/z
>   Logical volume "z" successfully removed
> 
> grub-probe --target=device /
> /dev/mapper/vg-rootlv
> 
> grep " / " /proc/mounts
> rootfs / rootfs rw 0 0
> /dev/dm-1 / btrfs rw,relatime,space_cache 0 0
> 
> 
> Problem still reproduces.
> --
> 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
> 


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

  reply	other threads:[~2014-12-02  7:50 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-01 12:56 PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots MegaBrutal
2014-12-01 17:27 ` Robert White
2014-12-01 22:10   ` MegaBrutal
2014-12-01 23:24     ` Robert White
2014-12-02  0:15       ` MegaBrutal
2014-12-02  7:50         ` Goffredo Baroncelli [this message]
2014-12-02  8:28           ` MegaBrutal
2014-12-02 11:14             ` Goffredo Baroncelli
2014-12-02 11:54               ` Anand Jain
2014-12-02 12:23                 ` Austin S Hemmelgarn
2014-12-02 19:11                   ` Phillip Susi
2014-12-03  8:24                     ` Goffredo Baroncelli
2014-12-04  3:09                       ` Phillip Susi
2014-12-04  5:15                         ` Duncan
2014-12-04  8:20                           ` MegaBrutal
2014-12-04 13:14                             ` Duncan
2014-12-02 19:14                 ` Phillip Susi
2014-12-08  0:05                 ` Konstantin
2014-12-01 21:45 ` Konstantin
2014-12-02  5:47   ` MegaBrutal
2014-12-02 19:19   ` Phillip Susi
2014-12-03  3:01     ` Russell Coker
2014-12-08  0:32     ` Konstantin
2014-12-08 14:59       ` Phillip Susi
2014-12-08 22:25         ` Konstantin
2014-12-09 16:04           ` Phillip Susi
2014-12-10  3:10         ` Anand Jain
2014-12-10 15:57           ` Phillip Susi
2014-12-08 17:20       ` Robert White
2014-12-08 22:38         ` Konstantin
2014-12-08 23:17           ` Robert White

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=547D6F42.9000009@inwind.it \
    --to=kreijack@inwind.it \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=megabrutal@gmail.com \
    --cc=rwhite@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.