Sorry, that ascii tree came out awful and it looks like Z is the child of Y instead of Y1. I hope this one below looks better.
Y1-Y \ Z-X On Wed, Dec 30, 2020 at 5:56 PM john terragon <[email protected]> wrote: > > Hi. > I would like to maintain a tree-like hierarchical structure of > snapshots. Let me try to explain what I mean by that. > > Let's say I have a btrfs fs with just one subvolume X, and let's say > that a make a readonly snapshot Y of X. As far as I understand there > is a parent-child relation between Y (the parent) and X the child. > > Now let's say that after some time and modifications of X I do another > snapshot Z of X. Now the "temporal" stucture would be Y-Z-X. So X is > now the "child" of Z and Z is now the "child" of Y. The structure is a > path which is a special case of a tree. > > Now let's suppose that I want to start modify Y but I still want to be > able to have a parent of Z which I might use as a point of reference > for Z in a > send to somewhere. That is I want to be able to still do a send -p Y Z > to another btrfs filesystem where there is previously sent copy of Y > (which, remember, as of this point has been readonly and I'm just now > wanting to start to modify it). > The only thing I think I can do would be to make a readonly snapshot > Y1 of Y and make Y writeable (so that I can start modify it). At that > point the structure would be > > Y1-Y > \ > Z-X > > (yes my ascii art is atrocious...) which is a "proper" tree where Y1 > is the root with two children (Y and Z), Z has one child (X) and Y and > X are leaves. > Now, my question is, would Y1 still be usable in send -p Y1 Z, just > like Y was before becoming writeable and being modified? I would say > that Y1 would be just as good as the readonly original Y was as a > parent for Z in a send. But maybe there is some implementation detail > that escapes me and that prevents Y1 to be used as a perfect > replacement for the original Y. > I hope I was clear enough. > Thanks > John
