"Steinar H. Gunderson" <[EMAIL PROTECTED]> writes:
> On Mon, Aug 07, 2006 at 05:03:39PM +0200, Petter Reinholdtsen wrote:
>> I've tested this patch, and it proved to be incomplete. ext2prepare
>> need an argument extra, with the new maximum size for the partition.
>> Not sure how to properly calculate that value, so I just picked a
>> fairly large number 100 GiB as the value. With this patch,
>> ext2prepare seem to run successfully.
100GiB is either way to high (for my 200MB / partition) or way too low
(for my 1TiB data partition). I think the value should be less than
16TiB (maximum size) and no more than 10 times the filesystem size.
> This seems like a "works by accident" hack to me. To be honest, I think we
> should be using mkfs.ext3 instead of partman to generate ext3 filesystems --
> no munging around with tune2fs, fsck or ext2prepare to create filesystems
> with the options we want (and who knows what is the next option added).
>
> I'm aware that mkfs.ext3 has no progress bar, but isn't it more important
> to generate correct file systems that having progress bars? Cc-ing
> debian-boot.
>
> /* Steinar */
mke2fs gives a progress for the first half but not for finalizing
the filesystem. If one guesses that the first half takes 90% of the
time then using that the progress would go smoothly from 0 to
90, stay there for a while and then jump to 100.
It would probably be worth a patch to mke2fs to output in D-I progress
format though instead of parsing the current output and translating
that.
But all of this won't remove the need for ext2prepare. Afaik there is
no option for mke2fs to build a filesystem already perpared for
resizing.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
