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
--
Fedora-livecd-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/fedora-livecd-list
