[Fedora-livecd-list] [PATCH 6/7] anaconda: liveinst.sh: support turboLiveInst/genMinInstDelta
Douglas McClendon
dmc.fedora at filteredperception.org
Tue Sep 18 20:15:30 UTC 2007
Douglas McClendon wrote:
> Douglas McClendon wrote:
>> Jeremy Katz wrote:
>>> On Mon, 2007-09-17 at 22:31 -0500, Douglas McClendon wrote:
>>>> Jeremy Katz wrote:
>>
>>>> The danger would be loop117, as that is the one created at install
>>>> time. loop118 being locked up at initramfs time.
>>>
>>> Not if new anaconda is used with old livecd-creator -- then loop118
>>> wouldn't have been used and something else could use it while the live
>>> system is running.
>>
>> This is true, albeit unlikely as well. But also fixable by addressing
>> the hardcoded loop device issue across the board.
>>
>>>
>>>> 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.
>>>
>>> But the time that the memory hit matters the _most_ is during the
>>> install as we have to have swap disabled during parts of it.
>>
>> Obviously this is your call, and from my perspective not a big deal
>> either way. My own personal preference still remains freeing up the
>> 1.2M of ram during all times other than the install, at the expense of
>> the complexity being in anaconda/liveinst.sh, versus being in initramfs.
>>
>> Perhaps by F9 I'll find a mechanism to achieve this that you like...
>
> Or maybe in significantly less time than that...
>
> How's this-
>
> 1) In initramfs, instead of lazy unmounting the squashfs, bindmount it
> to /sysroot/mnt/.LiveOS/squashfs
bindmount/movemount, whatever...
>
> 2) store osmin 'uncompressed' on the squashfs
>
> 3) in initramfs, set up the osimg-min device, but now with the loop118
> pointing at /sysroot/mnt/.LiveOS/squashfs/osmin
>
> The result- All the same low-impact that the current method has with
> anaconda, but the 1.2M of ram will only get used when anaconda actually
> starts touching /dev/mapper/live-osimg-min
>
> And given that it is a 1.2M file that compresses to 7kb, I'm assuming
> that squashfs will basically read and uncompress it only once. (and if
> memory is so constrained that during installation it gets swapped out,
> it's probably a good thing that that is possible and squashfs may read
> and uncompress it again).
swapout/dropped-from-buffer/squashfs/page-cache, whatever...
> By jeeves, I think we've got it. (correct me if I'm wrong or missing
> something)
>
> Thanks for being so stubborn :)
>
> -dmc
>
>
>> Otherwise,
>>> swap is available and can be used. It also means that there's less need
>>> to worry about the cleanup case in anaconda. Also, it takes care of my
>>> biggest complaint from the past (anaconda having to know too many
>>> details of how things are setup -- I _really_ like that right now,
>>> anaconda just needs to know to look at block device that's already set
>>> up and nothing more is needed)
>>>
>>> Patch ends up being the attached plus the teensy change so that anaconda
>>> will check /dev/mapper/live-osimg-min
>>
>> Looks fine to me. Thanks for the merge work.
>>
>> Now I'll move on to seeing what I can do in the next couple days with
>> that persistence patch. And maybe some other interesting things after
>> that... ;)
>>
>> peace...
>>
>> -dmc
>>
>> P.S.- I'm still curious on that davej ping regarding unionfs.
>>
>> --
>> Fedora-livecd-list mailing list
>> Fedora-livecd-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-livecd-list
>
> --
> Fedora-livecd-list mailing list
> Fedora-livecd-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-livecd-list
More information about the Fedora-livecd-list
mailing list