On Oct 28, 2012, at 3:25 AM, Goffredo Baroncelli <kreij...@inwind.it> wrote: > On Sun, Oct 28, 2012 at 12:22 AM, Chris Murphy <li...@colorremedies.com> > wrote:
> On my computer, when update-grub is called, it scans for all the > subvolumes and show them in the menu, allowing the user to switch at > boot time. If they can go in a snapshots submenu, fine. But UI wise, messy and not inherently a good idea to expose to regular Joe user in the main menu. What's the kernel parameter rootflags= line they're using? Is it a subvol hard path or subvolid? >> If it were to create entries potentially for every snapshotted >> system, it would be a very messy grub.cfg indeed. > > I don't think so. If a subvolume has a /sbin/int and and /etc it would > be suitable to be used as root filesystem. I understand it's suitable in that it will work. I'm just saying I don't want to see it by default in a menu. I do want to have to go dig for it, because most people most of the time won't have a need to use them. So in the main menu an option 'Snapshots' or 'Previous Systems' to reveal the snapshot list makes sense. On Oct 28, 2012, at 3:38 AM, "Fajar A. Nugraha" <l...@fajar.net> wrote: >> What's the UI? > > Grub boot menu. If the UI for switching between subvols is via grub, that means no dependency on 'subvolume set-default'. While you can call the root subvolume absolutely with rootflags=subvol=/hardpath/here/ or rootflags=subvolid=, what about the boot subvol? That's always a relative path as far as I can tell. So is the grub boot menu itself, i.e. t he grub.cfg that's used depends on the set-default. Are Ubuntu snapshots based just on snapshotting the root subvolume and keeping all possible kernels in a boot subvolume? >> Is this properly the domain of GRUB2 or something else? > > In my setup I use grub2's "configfile" ability. Which basically does a > "go evaluate this other menu config file". *sigh* two GRUB menus. Twice the pain, three times the mischief. But I understand how this works. >> On BIOS machines, perhaps GRUB. On UEFI, I'd say distinctly not GRUB (I >> think it's a distinctly bad idea to have a combined boot manager and >> bootloader in a UEFI context, but that's a separate debate). > > I don't use UEFI. But the general idea is to have one bootloader which > can load additional config files. And the location of that additional > config file depends on which BE user wants to boot. Therein lies some confusion to answer the question of how to organize snapshots and boot from them. Various boot managers and boot loaders should be taken into account, and UEFI firmware implication should be taken into account as well. > IMHO the biggest difference is that grub support for zfsonlinux, even > though it has bootfs pool property, has a way to reference ALL > versions of a file (including grub.cfg/kernel/initrd) during boot > time. This way you don't even need to change bootfs whenever you want > to change to a boot environment, you simply choose (or write) a > different grub stanza to boot. > > If we continue to rely on current btrfs grub support, unfortunately we > can't have the same thing. And the closest thing would be > "set-default". Which IMHO is VERY messy. I'm not entirely familiar with how ZFS implements snapshots or grub's support for them. But it sonds like the bootfs pool property supports absolute path names everywhere, including from within the GRUB core.img? So you're suggesting a GRUB2 limitation when it comes to btrfs? Fedora has also a limitation where kernel updates are still using grubby, not grub-mkconfig. That's also a problem IMO. It basically just takes the current entry and makes a kernel modification. If a snapshot is produced with each upgrade, the resulting grub.cfg will not be aware of or point to demoted kernels in snapshots. So if GRUB is a weak link for btrfs support, grubby is a weaker link. Will btrfs send / receive for snapshotting produce large storage requirements isn't it? If I send a current subvol to another subvol as a snapshot, am I not effectively making a copy of that whole sub-filesystem? Whereas 'subvolume snapshot' just does this with metadata, no meaningful additional space required. Only the updated files consume more space, regardless of which snapshot they're applied to. Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
