[Fedora-livecd-list] installer efficiency - sparse hackery

Douglas McClendon dmc.fedora at filteredperception.org
Tue Aug 21 02:21:28 UTC 2007


Out of curiosity Jeremy, in your envisioned sparse-feature method 
alternative to turboLiveInst-

How do you envision detecting which 0s in the file are legitimate data 
that needs to get written to disk, and which are unnecessary unwritten 
parts of the file?

I took a look at the tar --sparse documentation, which suggests that it 
handles sparseness by doing a complete extra read of the whole file, to 
detect 0s.  As mentioned, because what you are talking about is _not_ an 
actual sparse copy, there may be legitimate 0s that need to be written 
in our case.

It seems the only way would be to write a tool, which utilizes "intimate 
knowledge of ext3fs filesystem internals" to detect the appropriate 
place of holes in the file.

Can I just ask you - please - until you have a specific complete plan 
for an alternate solution, just go ahead and commit turboLiveInst for 
f8test2.  If you come up with a better cleaner solution (even if only in 
your opinion), I promise not to utter one word of complaint after you 
remove turboLiveInst.

I mean, you've already been down the path of suggesting a file-level 
copy.  That turned out to have a 5X slowdown performance penalty.  Now 
you are going down the path of this sparse copy, which is an incomplete 
solution, that despite what you've said, is not simply an elegant 
implementation of sparse support in python's shutil.copy.  Rather, it is 
at least as much of a hack as what I did.  And I maintain that 
turboLiveInst is not a hack, but an elegant use of devicemapper 
snapshot, which is the same elegant mechanism responsible for the 
fedora7 livecd in the first place.  Getting more exposure to 
devicemapper shapshot usage in the developer community - is a good 
thing.  It is a wonderful tool, that I'm sure will see many elegant uses 
in the coming years.

Regards,

-dmc




More information about the livecd mailing list