On Oct 15, 2013, at 8:45 PM, Andrey Borzenkov <arvidj...@gmail.com> wrote:
> В Tue, 15 Oct 2013 13:47:14 -0600 > Chris Murphy <li...@colorremedies.com> пишет: > >> >>> I'm not sure when and how top level may become != 5. >> >> starting where you left off with the sub2 subvolume mounted >> >> # btrfs subvol create /mnt/nested >> # btrfs subvol list /mnt >> ID 262 gen 135 top level 5 path dir1/sub1 >> ID 263 gen 140 top level 5 path dir2/sub2 >> ID 264 gen 140 top level 263 path nested >> > > Now try to remount with subvolid=0 and you will see that all subvolumes > have top level == 5. But the path is also different: ID 264 gen 165 top level 5 path dir2/sub2/nested So this is consistent behavior. From the top level 5 the path is dir2/sub2/nested, whereas from top level 263 the path is nested. Means the same thing. > Now "parent" is more interesting because it really tells us parent > subvolume and it permanent on-disk property. Yes I wish there were some metadata support so that it's possible for the application layer to understand the relationship between subvolumes better; e.g. so that all snapshots for an OS can be co-located in a listing, and sorted by recency. That way it's possible to do rollbacks at boot time to the next most recent "snapshot" of the system. It looks like right now this is up to naming and hierarchy strategy. Presently, at least one OS installer becomes confused and lists, without distinction, every OS snapshot regardless of location as if it were a unique installation. So a file system with 50 snapshots of rootfs, looks in the installer as if there are 50 unique installations of the OS. Confusing. However, an explicit "parent" concept might be difficult because a snapshot of a subvolume is a subvolume. I can delete either the original "parent" or the new snapshot and the other remains intact. The "parent" does not need to be retained as a backing for the snapshot. So really a snapshot is not as much a specific thing as it is an activity, and this same behavior applies to the new LVM thin provisioning snapshots as well. Chris Murphy _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel