Re: unit sizes and parted

[Andreas Dilger]

On Jan 29, 2002  23:53 +1100, Andrew Clausen wrote:
> On Mon, Jan 28, 2002 at 10:13:09AM -0700, Andreas Dilger wrote:
> > I'm wondering about the unit sizes for parted and why they were chosen as
> > such.  It appears that they are MiB (1024 KiB), but I can't find any way
> > to change them to other units like sectors, kiB, or cylinders.
> 
> Right.  I intend to change this.  MB would probably be a more
> appropriate default?  Just, I think it would be better (for
> the users TM) if I changed this over at the same time as introducing
> unit support.

Well, I'm agnostic to either MiB or MB (1000 KiB).

> > For DOS partitioning, doesn't everything have to align to cylinder
> > boundaries when creating the partitions so that MS DOS/Win can read
> > them?  So I would think that parted will munge the values to meet the
> > constraints of the partition type,
> 
> It does
> 
> > but testing shows that it creates fat32 partitions exactly
> > where you specify.
> 
> This means parted couldn't figure out the geometry on your
> disk... it should have told you.

Well, it didn't mention it, but yes, it was a file and not a disk device.
I figured that out after I sent my email, and hence the "need to be able
to specify a geometry" in my second email.

> > Also, it appears there is no way to "test" anything with parted.  With fdisk
> > and such, if you change things that you don't like, you just don't 'write'
> > at the end, but it appears that everything you do in parted happens right
> > away.  There also doesn't appear to be a way to "undo" your changes.
> 
> Right.  This would require operation queues (transaction sets?),
> and a whole lot of bureaucracy which is a great idea, but not
> implemented yet.  Fdisk doesn't have to predict stuff like what
> the constraint on resizing a file system will be after copying it,
> etc.  The API has slowly been moving to be friendly to such an
> implementation.

Well, for complete recoverability, that would be needed.  However, even
basic recoverability would help.  For example, before I realized that
there was no "undo" function I _almost_ wiped the partition table on
my primary machine because I wanted to see what GPT partitions looked
like (it is perfectly safe to play around with fdisk until you hit "w").
Luckily, I decided I should use a test file instead.

Having a backup copy of either the binary or logical structure of an
existing partition table would be a huge benefit at very little expense.
This might be similar to what LILO does when it first writes the MBR,
or the "sfdisk -O <file>" option.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/