Re: Parted, IA64 and ReiserFS

[Andrew Clausen]

Hi Matt,

On Thu, Sep 13, 2001 at 05:22:39PM -0500, address@hidden wrote:
> > I'm looking at parted and GPT again today finally.
> 
> OK, new GPT patch against 1.4.18 posted at http://domsch.com/linux/parted/
> with today's date.  A quick test shows that reiserfs is recognized just
> fine. :-)

;)

> Andrew, this doesn't address some of your concerns, but it does others.
> Specifically, in gpt_write(), I grab the start and end of each partition and
> stick it on-disk, so that move and resize work.

OK, well, that should work now, so I'm applying the patch... :)

> I didn't change
> gpt_partition_new() because, best as my feeble mind can tell, I'm doing the
> equivalent there as all the other labels.

The problem is some information is stored in PedPartition (start/end for
example), and other information is stored in the on-disk struct.  So, when
it comes to writing, you have to sync PARTS of the on-disk struct.  This
is very ugly, but I guess it's no disaster.  The alternative is to only
store information you care about in the partitions (yet another struct,
but this makes sense, since it's private partition data... i.e. stuff that
isn't common to all partition table types), and when you create the on-disk
stuff, you convert everything.  This is nicer because it's consistent,
and it's clear which direction the information flows...

A bigger problem is gpt_create().  In 1.5.x, I changed the semantics for
this a fair bit, so you can create new partition tables "in memory" without
touching the disk.  (so, there should be gpt_alloc() in 1.5.x that
returns a blank table)

> Each label has its own way of
> representing the various flags (RAID, LVM, boot, etc).  Rather than keep a
> separate pile of variables around, then reading through the pile and writing
> out the on-disk stuff, I change the on-disk equivalents when asked.  Except
> for move/resize, which should be fine now.

I prefer the separate pile of variables, because it's fairly easy to
understand how it works.

> Also, about gpt_probe().  It's doing the same as gpt_read() essentially, as
> the probe is designed to return "yes, this is my disk", but I can only do
> that *after* reading all the structures and making sure the CRCs match.  So,
> probing requires a full read/fixup-if-necessary (which it automatically
> does).

Sounds sane :)

Also, do you think it's wise saying all GPT partitions have "lba" set?
If the flag is *always* set... well, I guess it will make people feel a
bit safer seeing those magic letters... ;)

Thanks Matt!
Andrew