23.01.2019 16:52, Dennis Katsonis пишет: > On 1/23/19 10: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. > > >> >>> 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).
You cannot have your cake and eat it. Either you want it to be fool proof or you want extreme flexibility. In the former case it must block certain dangerous actions. In the latter case it is up to you - you got what you asked for. > If they do modify ANY subvolume created by > btrfs-receive, they must remember in the future somehow never to use > them as parents. > Both NetApp and ZFS distinguish between read-only snapshots and read-write clones. If you want to obtain read-write access to data in snapshot you clone it. May be we should at least think about why this workflow did not change in 25+ years. Problem discussed in this thread simply cannot happen there.
