Re: PedUnit API commit and partition resizing (blending "Re: PedUnit API commit" and "Re: partition resizing")

[Michael Reed]

Andrew Clausen wrote:
> On Wed, Jul 06, 2005 at 08:59:23PM +0200, address@hidden wrote:
>>>(parted) unit B
>>>(parted) mkpart
>>>Partition type?  [primary]?
>>>File system type?  [ext2]?
>>>Start? 0
>>>End? -1
>>>Error: The location -1 is outside of the device /dev/sdx.
>>Does this only happen with gpt labels?
> 
> Well, -1B is very strange.  How should we deal with byte units that
> aren't sector aligned?

I think that partitioning in units smaller than a sector
doesn't really make sense.  Otherwise, I think you should
round up/down to the nearest sector.

> 
>>>Using units GB, mkpart works but wastes quite a bit
>>>of space at the end of the disk.  Is this really the way you
>>>want it to work, leaving almost a GB of unused space at the end of
>>>the disk?  I'd consider changing the semantics of "-1"
>>>to be "last available sector relative to the starting sector
>>>regardless of unit in effect".  This means that if you're trying
>>>to fill a hole in the disk, all you have to do is get the starting
>>>location correct and -1 will find the end.  Anyway, something to think
>>>about.
>>Special semantics for ``-1''?
>>This introduces an inconsistency. You can always use ``-1s''.

-1s doesn't adequately describe what I had in mind.

I'm really suggesting "-1" mean "all available freespace" rather
than "end of disk -1 unit".

Parted could suggest an appropriate ending value as defined above
then I could just hit "return".

> 
> We could just make _grow_over_small_freespace() a more generous
> _grow_over_freespace(), constrained by our new "range" parameter.

I like this idea.  I'd like the growth over small freespace to
reach the end of the disk.  That's where the "all available
freespace" connotation for -1 would be handy.

(As you can tell, I'm more into the practical implications of
using parted than the elegance of the algorithm.  :(  )

> 
>>>I'd still like to see resize of a partition with no filesystem.
>>>(Patch previously submitted to maintainer(s).)
> 
> I'm not excited by the idea.  Would letting the "check" command set the
> partition size to coincide with the detected filesystem's size suffice?

You missed the point.  There is not a filesystem in the partition being
resized.  I just want to resize the partition.  What would "check" do
if there isn't a filesystem?

Thanks,
 Mike

> 
> Cheers,
> Andrew
> 
> 
> 
> _______________________________________________
> Bug-parted mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/bug-parted
> 
>