[Fedora-livecd-list] [PATCH] cleanupDeleted and container_size - saves 5.5% output size on f7livecd-i686

[Douglas McClendon]

Jeremy Katz wrote:
> On Fri, 2007-08-17 at 16:02 -0500, Douglas McClendon wrote:
>> Phillip Lougher wrote:
>>> Douglas McClendon-2 wrote:
>>>> Douglas McClendon wrote:
>>> Some stats based on the Fedora-8-Test-1-Live-i686.iso 
>>>
>>> original squashfs.img 712495104 (681M)
>>> sparse squashfs.img 709820416 (678M)
>>> sparse squashfs.img with 128Kbyte blocks 700100608 (669M)
>>>
>>> So, the compressed 0s used to take up about 2.5 Mbytes.  More significant is
>>> the data and seek time saving in not reading all these useless compressed
>>> 0s.
>>>
>>> time to do "dd if=os.img of=/dev/null" from CDROM
>>>
>>> original squashfs.img, 221 seconds
>>> sparse squashfs.img, 168 seconds
>>> sparse squashfs.img with 128byte blocks, 171 seconds
>>>
>>> on average about 20% speedup.
>> 20% speedup of reading data into /dev/null isn't all that useful.
>>
>> You didn't really mention what you were planning on using it for. 
>> Presumably you were also aware of my turboLiveInst patch, which 
>> accomplishes the 20% speedup in an actual copy situation.
>>
>> The sparse support could be used, perhaps with more code being written 
>> to support sparse copying to block devices with python, to gain the 
>> performance enhancements of turboLiveInst in an alternate manner.
> 
> I suspect that it can...
> 
>> For reasons that I can only speculate to, Jeremy, and everyone else 
>> seems to have no interest in my turboLiveInst optimization approach. 
>> Perhaps this method will be more palatable for them for some reason.
> 

> It's a bit more palatable because it's not playing tricks with
> device-mapper and instead makes things know about sparse files and deal
> with them as sparse files.  

"not playing tricks?!?!".  Have you been smoking crack?  Tell me how 
implementing a new procedure, that involves copying a sparse file, but 
letting the destination have data preserved where the data in the sparse 
file is zeros, is any less "playing tricks" than the proven code I've 
already presented?  I would argue that it is playing *more* tricks.  Do 
you really want to get developers in the mindset that the _appropriate_ 
behavior for a sparse copy is to have the destination retain data, 
instead of having the destination match the source?



> Which then makes the solution more general

Again- yer wrong.  Sorry there is no more diplomatic way to put it.  But 
that statement is completely, utterly, wrong.  Name one specific way 
that makes the as-yet-to-be-written 'fake sparse copy' solution more 
general than the already-written-and-tested turboLiveInst solution?

Name just one way.

-dmc