[Fedora-livecd-list] [PATCH 6/7] anaconda: liveinst.sh: support turboLiveInst/genMinInstDelta

[Douglas McClendon]

Jeremy Katz wrote:
> On Tue, 2007-09-18 at 15:09 -0500, 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
>>
>> 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
> 
> Okay, one better -- what if we just delay the lazy unmount of /squashfs
> until after we've done the osimg-min setup.  There's no reason it has to
> be mounted under the sysroot, we just have to wait to unmount the
> squashed copy.

Yeah.  The thought occurred to me because I was doing the movemounting 
myself for other reasons.  You are right, movemounting has nothing to do 
with the issue.

> 
> Although then the other question is what to do when we're not squashed.
> Do we just then want to put it on the ext3fs?

Here is the heart of something I think I mentioned that was wrong a long 
time ago.  I mentioned something like "osmin can't live on the squashfs 
for obvious reasons".  Actually, the truth is "osmin can't live on the 
ext3 for obvious reasons".  And the subtle error there kept the idea out 
of my mind.

In case it's not obvious- osmin must be created after os.img is final.

But...

It occurs to me that because of what anaconda is doing, I.e. a big 2G 
dd, it may actually be problematic that squashfs pages out(?) the osmin 
data, and needs to reread it from cdrom often, thus screwing up a nice 
big linear seek-free read.

My first thought is to do a performance test, and see what happens and 
if it matters.

For now, as is, is good enough.  We'll see if it can be made better.

-dmc