All of lore.kernel.org
 help / color / mirror / Atom feed
From: Goffredo Baroncelli <kreijack@libero.it>
To: Arnd Hannemann <arnd@arndnet.de>
Cc: Christian Robert <christian.robert@polymtl.ca>,
	linux-btrfs@vger.kernel.org
Subject: Re: 3.5.0-rc6: btrfs and LVM snapshots -> wrong devicename in /proc/mounts
Date: Tue, 10 Jul 2012 20:42:09 +0200	[thread overview]
Message-ID: <4FFC7781.5020002@libero.it> (raw)
In-Reply-To: <4FFC6C89.6030303@libero.it>

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


  reply	other threads:[~2012-07-10 18:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-09 22:22 3.5.0-rc6: btrfs and LVM snapshots -> wrong devicename in /proc/mounts Arnd Hannemann
2012-07-09 22:49 ` cwillu
2012-07-10  9:03   ` Arnd Hannemann
     [not found] ` <4FFBA1C8.9020502@polymtl.ca>
2012-07-10  8:52   ` Arnd Hannemann
2012-07-10 17:55     ` Goffredo Baroncelli
2012-07-10 18:42       ` Goffredo Baroncelli [this message]
2012-07-10 20:09         ` Arnd Hannemann

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=4FFC7781.5020002@libero.it \
    --to=kreijack@libero.it \
    --cc=arnd@arndnet.de \
    --cc=christian.robert@polymtl.ca \
    --cc=kreijack@inwind.it \
    --cc=linux-btrfs@vger.kernel.org \
    /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.