From: Hugo Mills <hugo@carfax.org.uk>
To: "Kevin O'Kelley" <kevin@kevinokelley.com>
Cc: Gabriel de Perthuis <g2p.code@gmail.com>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: Two identical copies of an image mounted result in changes to both images if only one is modified
Date: Thu, 20 Jun 2013 14:28:29 +0100 [thread overview]
Message-ID: <20130620132829.GP11290@carfax.org.uk> (raw)
In-Reply-To: <FDFB4977-0209-4F58-92CB-EF80E3575873@kevinokelley.com>
[-- Attachment #1: Type: text/plain, Size: 2575 bytes --]
On Thu, Jun 20, 2013 at 08:22:12AM -0500, Kevin O'Kelley wrote:
> Thank you for your reply. I appreciate it. Unfortunately this issue
> is a deal killer for us. The ability to take very fast snapshots and
> replicate them to another site is key for us. We just can't us Btrfs
> with this setup. That's too bad. Good luck and thank you.
If you want to make fast atomic incremental copies of btrfs to a
remote system, then btrfs send/receive may be what you're looking for.
Hugo.
> Sent from my iPhone
>
> On Jun 20, 2013, at 5:56 AM, Hugo Mills <hugo@carfax.org.uk> wrote:
>
> > On Thu, Jun 20, 2013 at 10:41:53AM +0000, Gabriel de Perthuis wrote:
> >>>> Instead of redirecting to a different block device, Btrfs could and
> >>>> should refuse to mount an already-mounted superblock when the block
> >>>> device doesn't match, somewhere in or below btrfs_mount. Registering
> >>>> extra, distinct superblocks for an already mounted raid is a different
> >>>> matter, but that isn't done through the mount syscall anyway.
> >>>
> >>> The problem here is that you could quite legitimately mount
> >>> /dev/sda (with UUID=AA1234) on, say, /mnt/fs-a, and /dev/sdb (with
> >>> UUID=AA1234) on /mnt/fs-b -- _provided_ that /dev/sda and /dev/sdb are
> >>> both part of the same filesystem. So you can't simply prevent mounting
> >>> based on the device that the mount's being done with.
> >>
> >> Okay. The check should rely on a list of known block devices
> >> for a given filesystem uuid.
> >
> > And this is where we fail currently -- that list is held by the
> > btrfs module in the kernel, and is constructed on the basis of what
> > "btrfs dev scan" finds by looking at superblocks on block devices.
> > Currently, there's no method implemented for determining whether a
> > block device with a legitimate btrfs superblock on it is a duplicate
> > of another device, or whether it's a newly-discovered device which is
> > part of an as-yet incompletely specified multi-device FS.
> >
> > I think it should be possible to look up the device ID as well, and
> > complain (loudly, to the user, and in the kernel) at btrfs dev scan
> > time if we see duplicates. That would deal with the problem at the
> > earliest point of confusion.
> >
> > Hugo.
> >
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- Computer Science is not about computers, any more than ---
astronomy is about telescopes.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2013-06-20 13:28 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-20 8:47 Two identical copies of an image mounted result in changes to both images if only one is modified Clemens Eisserer
2013-06-20 9:11 ` Fajar A. Nugraha
2013-06-20 9:16 ` Hugo Mills
2013-06-20 10:22 ` Gabriel de Perthuis
2013-06-20 10:34 ` Hugo Mills
2013-06-20 10:41 ` Gabriel de Perthuis
2013-06-20 10:56 ` Hugo Mills
2013-06-20 13:22 ` Kevin O'Kelley
2013-06-20 13:28 ` Hugo Mills [this message]
2013-06-20 13:29 ` Gabriel
2013-06-20 13:32 ` Hugo Mills
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=20130620132829.GP11290@carfax.org.uk \
--to=hugo@carfax.org.uk \
--cc=g2p.code@gmail.com \
--cc=kevin@kevinokelley.com \
--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.