On 1/23/19 10:25 PM, Andrei Borzenkov wrote: > On Wed, Jan 23, 2019 at 1:45 PM Dennis Katsonis <dennisk@xxxxxxxxxxxxxxx> 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. > >> This can happen inadvertently, > > It cannot. You do not inadvertently make subvolume read-write. It's not the individual steps which happen inadvertently, its that particular workflow which can happen (i.e.; someone decides to play around with a replicated snapshot, and flips the ro bit to do so). Any subsequent children sent later won't be true replicates on the receiving end. They would have to either make a habit of not flipping that ro bit at all (there is nothing to say don't do it, and there are valid reasons to do so) or anticipate they may need that subvolume as a parent anytime in the future and that parents must be the same on both ends (there is nothing which states that parents have to be identical on both ends for btrfs-receive to operate). If they do modify ANY subvolume created by btrfs-receive, they must remember in the future somehow never to use them as parents. BTRFS allows an ad-hoc, unstructured approach to managing snapshots and replication, but the cost I suppose is there are more corner cases and more potential for users to use the system in a manner which differs from the devs. > > That said, better if btrfs did not allow flipping read-only bit in the > first place. > >> 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. >If the tools can't prevent it, the documentation should, and should also ideally describe the mode of failure (i.e., if the subvolumes are different, btrfs-receive won't necessarily fail, but can produce a subvolume which is not identical to that sent. At the moment, one must infer that the statement that clones must be identical at both ends.
