Re: Two identical copies of an image mounted result in changes to both images if only one is modified

[Hugo Mills <hugo@carfax.org.uk>]

[-- Attachment #1: Type: text/plain, Size: 1894 bytes --]

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
                   --- I know of three kinds: hot, ---                   
                cool,  and what-time-does-the-tune-start?                

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]