- /boot on a thin LV - Grub2 support to be able to boot off thinp mappings (mind BIOS/EFI/... constraints)
I'm not convinced we need to support this feature. The complexity of this BZ is enormous compared with result - surely not 7.2 issue. IMHO superior solution here is to have bootable linear. We could simply dedicate LV for kernel & ramdisk - and grub would simply boot given kernel - having rootfs on thin is then no problem. Use could have numerous bootable LVs this way - so he could roolback to any previous kernel, it just needs to have some max number of LV to be maintained this way.
In RHEV-H we are storing a complete rootfs, including /boot, on a thin LV. Currently we are then copying the contents of /boot to a dedicated /boot partition which grub can access. With this RFE being implemented, we could just leave the kernel+initrd on the thin LVs, and just add the relevant boot entries. This would make the whole setup much cleaner, because each rootfs would be completely self contained, except for the boot entry. AFAIK grub2 already supports booting of normal snapshots, isn't this similar?
(In reply to Fabian Deutsch from comment #2) > In RHEV-H we are storing a complete rootfs, including /boot, on a thin LV. > Currently we are then copying the contents of /boot to a dedicated /boot > partition which grub can access. > > With this RFE being implemented, we could just leave the kernel+initrd on > the thin LVs, and just add the relevant boot entries. > This would make the whole setup much cleaner, because each rootfs would be > completely self contained, except for the boot entry. > > > AFAIK grub2 already supports booting of normal snapshots, isn't this similar? Nope - it's very different. The complexity of booting from thin is extreme compared with plain linear volume. If you would have /boot dir as member of your root thin LV - then basically grub would need to understand whole thin-mapping - parsing thin-metadata and ensure all sector read request follow the mapping - basically placing whole thin-target into Grub in some way. This is very complex and IMHO not ever worth the effort - compared with fairly simple support for mapping boot out of some small 'linear' LV. That might be theoretically a bit complex as well - since the minimal supported extent size is 512B and you may need lot of such sectors for i.e. 30MiB LV - but still it far less complex then implementing thin target support in grub and in the real-world with extent size 4MiB very simply to reach.
Right, I now understand the technical requirements a bit better.
(In reply to Fabian Deutsch from comment #4) > Right, I now understand the technical requirements a bit better. The main point here is that step of orders is already given - we need to be first able to boot from any 'plain' LV. Once we are able to this - we could start to think adding support for more complex scenarios. To boot from thin LV - mean - we have to be able to 'map' thin data & metadata LVs in some way - so 'grub2' would be able to read thin metadata. Then from this moment it may know how to prepare 'thin' device over thin-data device. As one can see - very complex to do in 'grub' with its limited resources.