Hi dibl,
No worries, in my tutorial I did the steps in a vm so thats why the disk is so small. However, again I don't think I am an expert on btrfs, but from my understanding of it, the snapshot won't take another 4GB, at least right away. What it does is say ok this is what the snapshot should look like. An oversimplified answer is as changes are made to the subvolume the snapshot essentially holds onto the original blocks that were changed. Realistically its actually tracking changes to both subvolumes.
So using the example earlier, where we snapshot prior to a d-u, lets say we do that an the only thing was the kernel got updated, then what should happen is the snapshot then only retains the original kernel prior to the d-u. So the snapshot will actually only hold that original kernel, the rest of the data is the same so it only holds one copy. Again I am just oversimplifying it, what actually happens is only the changed blocks get retained, imagine if the old kernel and the new kernel are 99% the same, that snapshot only actually holds 1% of that change.
The only time where the snapshot will take up the same amount of space as its parent is when the parent and subvolume are 100% different at the block level. Now that being said snapshots should not be used as a method of backing up data.
Hi Tim
No worries like I said you did nudge me in the right direction, this is an ugly way to do it, if the installer supported subvolumes we wouldn't have to clean up the root subvolume nor mess with grub. Looking into what you wanted to however, and it looks like the information might have been not so wrong. As I was going through the grub update scripts the problem maybe that I am not 100% sure if the method grub uses to find other os's if it will probe into other subvoumes outside the one its updating from. I guess the best way to find out is try it out in vm.
-Tareeq
