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
Show replies by date