Re: [Fedora-livecd-list] [PATCH] cleanupDeleted and container_size - saves 5.5% output size on f7livecd-i686
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