Mark McLoughlin wrote:
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 ?
If you mean already as in 'exists in the f7livecd' then the answer is no. The
resize2fs that the f7livecd anaconda does is _after_ the fs image copy, and thus
only effective for expansion, not shrink.
the f7livecd anaconda installer will red-error-of-death you if you try to
install to a 3G destination volume.
> 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 ...
Because you haven't yet added in-flight-resize2fs support to e2cp.
But if you don't care about fixing the 2.4G->3.9G destination volume problem,
then e2cp is sufficient.
-dmc
> 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.
--
Fedora-livecd-list mailing list
Fedora-livecd-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-livecd-list