Re: Parted 1.6.0-pre9

[Andrew Clausen]

On Wed, Apr 10, 2002 at 01:26:05PM +0100, Richard Hirst wrote:
> On Wed, Apr 10, 2002 at 02:20:19PM +1000, Andrew Clausen wrote:
> > Hi all,
> > 
> > Anything more to do?
> 
> Tried it on ia64:

Thanks for the checklist, hehe :)

> Oops!  I wanted hp-service support, but didn't want it by default on
> every new partition ;-)
> 
> gpt_partition_new() is missing a "gpt_part_data->hp_service = 0;".
> Seems to me it might make more sense to zero the whole gpt_part_data
> when creating a new partition.

Thanks.  Fixed.

> Also, I didn't see a response to my request to use double rather than
> long double in command_line_get_sector() to work round a gcc/glibc bug
> on hppa.  You might take the view that we should fix gcc/glibc, and I
> couldn't argue with that, but I think double is more than enough in
> this case.

Sorry, I'd forgotten... (since I was still thinking).
What's the number of mantissa (I've seen that word, but never seen
it defined...) bits on double's?

FWICT, it's 53 bits, which should be sufficient.  (2^(53 + 8) == 2^61
bytes, which is a lot of storage ;)

> I see there is also progress feedback in 1.6, which is nice, but in
> this case:
> 
> > (parted) mkpartfs primary ext2 200 300
> > writing per-group metadata... 100%      (time left 00:12)(parted)         
> 
> it failed to erase the progress line.

I've never seen this happen.  This is funky... it means someone isn't
saying they've finished.  (But it's at 100%!)  /me confused

> Actually, progress reporting is
> pretty eratic on this dual processor ia64 box, with 2G memory.  When
> mkpartfs ext2'ing a 3G partition I seem to get one of:
> 
> a) no progress report at all
> b) as above, percent count climbs up to 100% but (non-zero) time left
> remains unchanged, then the prompt is appended to the line
> c) as (b), but the time is initially displayed as 0:00, and doesn't
> change, but the line is erased correctly on completion
> 
> If I get a progress indication, it hits 100% long before the prompt
> returns, but I guess that is because of disk flushing.

There is definitely something strange happening there.  I've never
seen anything like it, and it doesn't make sense.  Can I debug it?
(ssh?)  Or, feel free to look yourself...

> I guess this is very hard to get right for short operations.  My
> mkpartfs takes about 7 seconds, but by the sound of the disk, and the
> 100% indication, I think parted is only running for about 1 second, and
> the rest is disk flushing.  Maybe the progress line could be replaced
> with "writing changes to disk" once it hits 100%.

I think it's a bug, not a "feature" ;)

> Next, I tried to create a partition over the top of an existing one:
> 
> > (parted) mkpartfs primary ext2 600 700
> > (parted) mkpartfs primary ext2 600 700                                    
> > Error: Attempt to read sectors 4294967294-4294967295 outside of partition 
> > on /dev/sdc
> > Ignore/Cancel? 

Ah, another bug: it was trying to make a really small file system,
and failing.  So, really two bugs: the "check distant solution" thing
was broken (now fixed), and the ext2 code was returning a too-small
constraint, and not checking it had enough inodes, etc.

> Under 1.4, trying to "set N swap on" with a gpt label would report
> that the flag was not supported for GPT, but 1.6 just silently ignores
> me.  Is that intentional?

This is a hard problem to solve, actually.  After the user types in,
say "set N * rubbish on", what do you do...?  (where * indicates where
we are up to parsing):
 (1) just ask the user again?
i.e. bring up:
        Partition flag? the/list/[like]/this?
This would involve "forgetting" the subsequent things the user typed.
(i.e. "on")

 (2) complain, and bail out of the command?

I think (1) makes sense for interactive mode, and (2) for script mode.

What would a complaint look like?  It'd be nice to generate this
from existing information available (the prompt ("Partition flag?"),
and the list of options)
Hmmm, perhaps just put the prompt from (1), and then quit/abort?

> Finally, I see that with a GPT label I can only create a partition up
> to 8MB from the end of the disk, but with msdos, I can get to within
> 1MB:
> 
> I don't know whether this is due to constraints or rounding errors, but
> it struck me as odd.

Ah, spot the bug:

        data_start = 2 + GPT_DEFAULT_PARTITION_ENTRY_ARRAY_SIZE / 512;
        data_end = dev->length - 2 - GPT_DEFAULT_PARTITION_ENTRY_ARRAY_SIZE;

Thanks :)

Andrew