On Wed, 2007-07-11 at 14:50 -0500, Douglas McClendon wrote:
The main downside I think it has as a solution to the issue, is that
it doesn't
fix the case of a destination volume of say 3.0G. I.e. there is no reason why
the livecd installer shouldn't be able to install it's 2.3G payload onto a 3.0G
destination.
I thought that was already covered with a resize2fs ?
The most recent solution I was proposing, involved taking a second
snapshot of
the 4.0G (or perhaps now 1T) sparse ext3 os.img file, and resize2fs-ing it down
to minimal, and then copying it.
This sounds like a way of doing the same thing as e2cp ... by resizing
it down to its minimal size, you'd be removing all unallocated data
blocks and so e2cp would have nothing to ignore.
So, they're different solutions to the "let's not copy unallocated
blocks" problem.
Not sure why a snapshot is needed ...
I.e. if you take an image, resize it to minimal, then resize it to
1TB, then
how long and how many changes will it take to resize it back down to minimal?
Of course I can just test it myself, and probably will soon enough.
I would imagine it would be similar to how long it would take to mke2fs
a 1TB sparse file.
Cheers,
Mark.