On Thu, 20 Jun 2013 10:16:22 +0100, Hugo Mills wrote: > On Thu, Jun 20, 2013 at 10:47:53AM +0200, Clemens Eisserer wrote: >> Hi, >> >> I've observed a rather strange behaviour while trying to mount two >> identical copies of the same image to different mount points. >> Each modification to one image is also performed in the second one. >> touch m2/hello >> ls -la m1 //will now also include a file calles "hello" >> >> Is this behaviour intentional and known or should I create a bug-report? > > It's known, and not desired behaviour. The problem is that you've > ended up with two filesystems with the same UUID, and the FS code gets > rather confused about that. The same problem exists with LVM snapshots > (or other block-device-layer copies). > > The solution is a combination of a tool to scan an image and change > the UUID (offline), and of some code in the kernel that detects when > it's being told about a duplicate image (rather than an additional > device in the same FS). Neither of these has been written yet, I'm > afraid. To clarify, the loop devices are properly distinct, but the first device ends up mounted twice. I've had a look at the vfs code, and it doesn't seem to be uuid-aware, which makes sense because the uuid is a property of the superblock and the fs structure doesn't expose it. It's a Btrfs problem. 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. >> I've deleted quite a bunch of files on my production system because of this... > > Oops. I'm sorry to hear that. :( > > Hugo. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
