On 24/1/19 3:23 am, Hans van Kranenburg wrote: > On 1/23/19 4:32 PM, Nikolay Borisov wrote: >> >> >> On 23.01.19 г. 17:25 ч., Hans van Kranenburg wrote: >>> On 1/23/19 12: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. 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. >> >> I had a patch which when the ro bit is flipped on a snapshot, then it's >> parent snapshot uuid etc is deleted. Because at that point it cannot be >> guaranteed that there is any relationship between paren<->snapshot. Ie: >> >> https://lore.kernel.org/linux-btrfs/1520847020-8049-1-git-send-email-nborisov@xxxxxxxx/ >> >> has anyone tried it? > > Oh, it seems that one never got any reply. > > When looking at it from an end user perspective, I'd much more like to > have it explicitly tell me I'm doing something stupid, refuse and > educate me than obeying and adding more implicit behaviour that I cannot > revert any more myself. > It was the new user I had primarily in mind. Btrfs is the default for OpenSUSE, and may become the default for more distros. Thats a lot of new users, unaware of the vaguaries of COW filesystems who first learn how to use the tools to solve their problems, before they learn the "gotchas". The fact is, this thread is the first time I've seen explicitly written that parents must be the same at receiving and sending ends, or else btrfs-send/receive will produce a subvolume which differs from the source. A user could from the descriptions of how send/receive formats its data strea, and from interpreting "clone sources" in a manner contrary to how its used in the man page and the mention of incrementals, conclude that send/receive is sensitive to changes at the receiving side, but its far, far more likely that they will start using feature like send/receive and setting snapshots to ro before they delve into how it works its magic. Anyway, rsync sends incremental change, and its ability to replicate a directory tree isn't predicated on the files present at the receiving end being the same as the last time it was run... > E.g. I'm a new btrfs user, I just sent this 1TiB of data for the first > time, and now I'm of course curious and trying more things out. > > Trying setting rw ('ooh! that works') and then quickly setting ro back > will destroy the send/receive relationship without mentioning anything > to the user, and in combination with subsequent cryptic errors from > incremental send/receive ("cannot find parent subvolume" or something) > it will end up with smashing keyboards and throwing computers out of the > window. > > After asking on IRC and providing output of btrfs sub list etc the user > is told that that subvol was never received because it doesn't have a > received_uuid, and then someone asks "did you turn it rw at some > point?". Now the user remembers, "yes, I was experimenting and I didn't > see an error or warning", and is then told to resend the 1TiB of data. > "But it's there already!" Now someone comes up with a snippet of python > code to reset the received_uuid with the ioctl, and... > > :D > >>>>> 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. >>>> >>> >>> > >
