Zach Brown posted on Wed, 23 Jul 2014 13:47:36 -0700 as excerpted: > On Wed, Jul 23, 2014 at 02:10:29PM -0600, Chris Murphy wrote: >> The use case is when it's possible to mount a Btrfs volume ro, but not >> rw. Example, a situation where >> >> # mount -o degraded /dev/sdb /mnt >> [...] BTRFS: too many missing devices, writeable mount is not allowed >> >> Yet this works: >> # mount -o degraded,ro /dev/sdb /mnt >> >> It would be great if it were possible to send/receive subvolumes to a >> different btrfs volume. Currently it's not possible because those >> subvols aren't ro, and because the mount is ro I can't make ro >> snapshots first. In general, btrfs send/receive is great when it works, but because there's still corner-cases like this as well as simply broken send/ receive cases popping up from time to time, I strongly recommend not relying on it working, and keeping a more conventional backup option (like rsync) tested-working and usable as well. > I wonder if that's as easy as the following totally untested hack. I > have no idea if a read-only mount would still allow background > modification that might violate the send code's assumptions. Hopefully that hack works. Meanwhile, AFAIK, yes, there's still cases where a read-only mount can still allow background mods that would violate send's assumptions. Tho I don't believe they apply in this case. But certainly, there has been recent discussion on the subvolume mount situation, since it's possible to access child subvolumes from writable-mount parent (including root/ id5) subvolumes, and currently nothing stops writing into the read-only- child's mount from the parent's writable mount. Even without that situation, however, there's bind-mounts, which start out with the same mount options as the original, but with a remount allow one of the views to be read-only while the other is writable, regardless of the filesystem. Obviously that allows changing the view on the read- only side from the writable side. So while having the ability to do a send from a read-only mount is indeed a good thing to have in emergency cases such as this, I'd suggest requiring a --force option or the like to enable it, since the full immutable-read-only guarantees simply aren't there. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- 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
