07.10.2017 00:27, Hans van Kranenburg пишет: > On 10/06/2017 10:07 PM, Andrei Borzenkov wrote: >> >> What is reason behind allowing change from ro to rw in the first place? >> What is the use case? > > I think this is a case of "well, nobody actually has been thinking of > the use cases ever, we just did something yolo" > > Btrfs does not make a difference between snapshots and clones. Other > systems like netapp and zfs do. Btrfs cloud also do that, and just not > expose the ro/rw flag to the outside. >
Current pure user-level implementation of btrfs receive requires possibility to switch from rw to ro. So it is not possible to completely hide it. This is different from both NetApp and ZFS. On NetApp destination volume/qtree are always read-only for client access. ZFS explicitly disallows any access to destination until transfer is complete. It was already mentioned that in btrfs destination may be changed before subvolume is changed to ro without anyone noticing it. Ideally btrfs receive needs exclusive access to subvolume with some sort of automatic cleanup if receive fails for any reason. This will ensure atomic (from end user PoV) transfer. > Personally, I would like btrfs to go into that direction, because it > just makes things more clear. This is a snapshot, you cannot touch it. > If you want to make changes, you have to make a rw clone of the snapshot. > > The nice thing for btrfs is that you can remove the snapshot after you > made the rw clone, which you cannot do on a NetApp filer. :o) > >>> Even if it wouldn't make sense for some reason, it's a nice thought >>> experiment. :) > > There we go :) > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
