On 1/23/19 12:25 PM, Andrei Borzenkov wrote: > On Wed, Jan 23, 2019 at 1:45 PM Dennis Katsonis <denn...@netspace.net.au> > wrote: >> I think my previous e-mail did not go through. Basically, if it is >> assumed that a btrfs-receive operation will result in a subvolume which >> matches the source file for file, then this assumption or expectation >> won't be met if one deletes files from the subvolume at the receiving >> end which is going to be referred to as the parent. >> > > This is oxymoron. btrfs send/receive apply to read-only subvolumes. > You are not able to modify them. As soon as you remove read-only bit, > you are fully responsible for consequences. > >> This can happen inadvertently, > > It cannot. You do not inadvertently make subvolume read-write. And if > you do, you are expected to know what you are doing. > > That said, better if btrfs did not allow flipping read-only bit in the > first place.
+100 But then only disallow if the subvol has a value in the received_uuid field, I'd say. And the tooling could display a nice error message, telling the user to make a rw snapshot of the received subvol instead, which will have an empty received_uuid field again. ERROR: subvolume is a received subvolume, which cannot be made read-write ERROR: suggestion; make a read-write snapshot of it instead Setting something ro manually (e.g. to prevent accidental deletion of a static set of data) is still also a use case. >> or even through filesystem corruption >> (which I experienced). >> > > And if corruption happened after applying changes? End result in the > same. Of course it would be perfect if btrfs could notice and warn > you, I just do not see how it can realistically be implemented. > -- Hans van Kranenburg
