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? > >>> 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. >> > >
