[Fedora-livecd-list] RFC- improving livecd installer efficiency

[Douglas McClendon]

Mark McLoughlin wrote:
> On Wed, 2007-07-11 at 14:50 -0500, Douglas McClendon wrote:
> 
>> The main downside I think it has as a solution to the issue, is that it doesn't 
>> fix the case of a destination volume of say 3.0G.  I.e. there is no reason why 
>> the livecd installer shouldn't be able to install it's 2.3G payload onto a 3.0G 
>> destination. 
> 
> 	I thought that was already covered with a resize2fs ?

If you mean already as in 'exists in the f7livecd' then the answer is no.  The 
resize2fs that the f7livecd anaconda does is _after_ the fs image copy, and thus 
only effective for expansion, not shrink.

the f7livecd anaconda installer will red-error-of-death you if you try to 
install to a 3G destination volume.


> 
>> The most recent solution I was proposing, involved taking a second snapshot of 
>> the 4.0G (or perhaps now 1T) sparse ext3 os.img file, and resize2fs-ing it down 
>> to minimal, and then copying it.
> 
> 	This sounds like a way of doing the same thing as e2cp ... by resizing
> it down to its minimal size, you'd be removing all unallocated data
> blocks and so e2cp would have nothing to ignore.
> 
> 	So, they're different solutions to the "let's not copy unallocated
> blocks" problem.
> 
> 	Not sure why a snapshot is needed ...


Because you haven't yet added in-flight-resize2fs support to e2cp.

But if you don't care about fixing the 2.4G->3.9G destination volume problem, 
then e2cp is sufficient.

-dmc


> 
>>   I.e. if you take an image, resize it to minimal, then resize it to 1TB, then 
>> how long and how many changes will it take to resize it back down to minimal? 
>> Of course I can just test it myself, and probably will soon enough.
> 
> 	I would imagine it would be similar to how long it would take to mke2fs
> a 1TB sparse file.
> 
> Cheers,
> Mark.
> 
> --
> Fedora-livecd-list mailing list
> Fedora-livecd-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-livecd-list