[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: partition resizing (was: Re: PedUnit API commit)

From: Szakacsits Szabolcs
Subject: Re: partition resizing (was: Re: PedUnit API commit)
Date: Fri, 8 Jul 2005 11:45:11 +0200 (MEST)

On Fri, 8 Jul 2005, Andrew Clausen wrote:
> On Thu, Jul 07, 2005 at 11:00:53PM +0300, Szakacsits Szabolcs wrote:
> > >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?
> > 
> > That sounds misnomer, illogical from resizing point of view. 'Check' 
> > suggests fsck, not resizing.
> Well, it is an error (or at least strange) to have a filesystem size !=
> partition size.  

It's not strange that they are different during the commonly used resizing
process, I've commented. It's a necessitate state during resizing a
filesystem on top of (inside) a container (partition, slice, etc).

> So, I think this it is logical for check to have this capability.  
> But I accept that users might find it strange that normal use of their
> computer involves repairing something that they apparently didn't
> break.

Yes, this is how users interpret your suggestion:

        1. run the filesystem resizer (resize2fs, resize_reiserfs,
           resize_reiser4, ntfsresize, etc)

        2. then run Parted using 'check' to repair the damage the above 
           tools made during step 1.

They will feel unconfortable. 

> > Here are some scenarios. What would be the most appropriate?
> > 
> > 1.  resize2fs|resize_reiserfs|resize_reiser4|ntfsresize
> >     parted resize
> My concern with this is that "resize" takes the new partition dimensions
> as parameters.  It could just ignore them, 

This sounds bad.

> or when reading them in interactively, it could explain the
> situation... 

Sounds better.

> did you have any particular UI in mind here?

E.g. user provides exactly the same what currently:

        resize partition start end

and Parted does so, or it reports if it's not possible and also why. 

If Parted doesn't support the filesystem then it does only the
repartitioning unless the end would intersect the filesystem or 
the partition start isn't the same (i.e. don't damage the fs).
> > 2.      resize2fs|resize_reiserfs|resize_reiser4|ntfsresize
> >     parted check
> > 
> > 3.  resize2fs|resize_reiserfs|resize_reiser4|ntfsresize
> >     parted align, adjust or whatever is the most expressive
> I think we should avoid cluttering the UI with more commands...

Parted as a command line partitioner (and I don't mean now the indeed
_widely_ used libparted) isn't very useful anymore. It only supports a few
not-so-widely used filesystems but none of the mainstream ones. Perhaps
it's worth "cluttering" the UI by a new command to make Parted a bit more

The above would mean that this new Parted command 

        fitpart 1 

could replace the curent way of non-destructive repartitioning if the
filesystem was already shrunken:

# fdisk /dev/hda

Command (m for help): p

Disk /dev/hda: 255 heads, 63 sectors, 2480 cylinders
Units = cylinders of 16065 * 512 bytes

   Device Boot    Start       End    Blocks   Id  System
/dev/hda1   *         1      2479  19912536    7  HPFS/NTFS

Command (m for help): d
Partition number (1-4): 1

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
Partition number (1-4): 1
First cylinder (1-2480, default 1): 1
Last cylinder or +size or +sizeM or +sizeK (1-2480, default 2480): +11140M 

Command (m for help): t
Partition number (1-4): 1
Hex code (type L to list codes): 7
Changed system type of partition 1 to 7 (HPFS/NTFS)

Command (m for help): a
Partition number (1-4): 1

Command (m for help): p

Disk /dev/hda: 255 heads, 63 sectors, 2480 cylinders
Units = cylinders of 16065 * 512 bytes

   Device Boot    Start       End    Blocks   Id  System
/dev/hda1   *         1      1355  10884006    7  HPFS/NTFS

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

BTW, I think I prefer the new 'fitpart' against extending 'resize'
semantics. Simpler, clearer.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]