[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