Jeremy Katz wrote:
On Mon, 2007-09-17 at 12:34 -0500, Douglas McClendon wrote:
this patch takes care of the anaconda side of taking advantage of
livecd's created with a livecd-tools that has
turboLiveInst/genMinInstDelta support. But the code does check for the
legacy situation, and handles it gracefully. Thus this patch is safe
even in the absence of the actual beneficial final patch to livecd-tools.
So as you alluded in your later mail, this looks like it could be
confused if something else ended up using loop118 instead. Is there a
good reason not to just set up the minimal snapshot from the initrd and
then just use it if it exists? That would then make the anaconda side
super-crazy-simple (look for /dev/mapper/live-osimg-min and use it if it
exists).
The danger would be loop117, as that is the one created at install time.
loop118 being locked up at initramfs time.
The reason why I think it should stay as is, instead of setting
everything up at initramfs time, is because the loop117 gets associated
with the decompressed-into-devshm contents of loop118. The
decompression being 7kb->1.2M in the typical case.
I'd say that the 1.2M ram hit should only be taken during install, and
that outweighs the benefits of moving the complexity from liveinst.sh to
initramfs.
And as for the theoretical possibility that loop117 could be in use,
that should be addressed by a forthcoming patch which removes all the
hardcoded loop device usage.
-dmc
The only downside I can see is that the snapshot is always set up which
probably has some resource cost, but I can't see it being that high.
Jeremy
--
Fedora-livecd-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/fedora-livecd-list
--
Fedora-livecd-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/fedora-livecd-list
