Re: Hacking parted to work with BSD disklabels ...

[Timshel Knoll]

On Tue, Oct 24, 2000 at 04:09:58PM +1100, Andrew Clausen wrote:
> EVERYONE!
> 
> I usually go on xnet irc (see www.xnet.org), on channel #gnu, on
> Saturday & Sunday mornings (~7:00 am -> 12:00) 
> 
> Everyone is invited to come along and chat ;-)
> 
> (actually, I'm often there other times as well, so come whenever
> you want ;-)
> 
> I really should post summaries of some of the discussions I've had
> with Lennert and Damien, and get them going on the mailing list...
> I'll have a bit more of time from next week, and lots more time from
> the end of November.
> 
> Anyway, IRC seems to be good for clearing up some Issues...

:-)

> 
> Timshel Knoll wrote:
> > > Sorry, what's the difference between the two types?  Do you mean
> > > "add a PedDiskType called bsd, and a PedPartitionType (or
> > > PedFileSystemType?) called bsd"?
> > 
> > Yes, this is what I'm saying - a bsdlabel is a PedDiskType, and a
> > bsdpart is a PedPartitionType. Much like the current extended/logical
> > arrangement.
> 
> OK.
> 
> I'm wondering: do we need a separate PedPartitionType?  Why not use
> PED_PARTITION_EXTENDED?  Then, use the partition flag interface to
> specifiy BSD or DOS "extended" partitions.

This is possible - and I had thought about it. The only issue is that
currently there's no real way of having more than 1 extended partition ...

> Other features (like max # of logical partitions) could be controlled,
> by interrogating the actual partition.
> 
> > > OK, this has Implications.  First, logical partitions
> > > (== sub-partitions) must have owners expressed explicitly.  i.e.
> > > a tree structure, with up links.
> > 
> > Yes, I think that this is probably the best way to do it. However,
> > this has other implications (ie. mkpart for logical partitions
> > will have to take an extra parameter than mkpart for primary partitions).
> 
> Perhaps:
> 
>       (parted) mkpart extended START END
>       (parted) set MINOR bsd on
> 
> One problem is: you can only have 1 MSDOS extended partition.  It
> could create a BSD one after exhausting MSDOS partitions, but this is
> yuck.  Ultra-yuck.
> 
> > > Can sub-partitions be nested?  Can sub-partitions exist in logical
> > > partitions?
> > 
> > No, I don't believe that you can have a disklabel within a disklabel ...
> > The exception of course is having a disklabel within a primary DOS
> > partition ...
> 
> huh?  why "primary"?  can't it be in a logical partition?

No, a BSD disklabel _must_ go in a primary partition at this stage.

> > > (/me REALLY should get freebsd...)
> > 
> > I'll burn you a copy if you want ... and it to you whenever we get
> > together (BTW, monday lunch might be good ... I'm going to Adelaide
> > this W/E and I just have to make sure that I'll be back ... I'll
> > get back to you on this tho). I've also got OpenBSD and NetBSD if
> > you want them as well. :-)
> 
> Sounds good :-)  BTW: this is my last week @ uni.  So, any day after
> that is equally ok, basically ;-)

OK, I'll let you know ...

> > > Also: do you have any inspiration on how to interface this stuff
> > > on Parted?  And libparted?  It would be nice to preserve the
> > > partition type (extended, logical, primary, etc.)...
> > 
> > I believe that it would be good to get rid of any disklabel-specific
> > stuff from all files other than disk_<disklabel-type>.c - ie. get
> > rid of all stuff regarding 'primary' partitions or 'extended/logical'
> > partitions from disk.c ... not that this is really possible, but
> > hey ...
> 
> Well, I think things that affect the interface (include/parted/disk.h)
> go in disk.c.  Removing logical/extended stuff from the interface
> isn't possible - users need control here.

Yes, I know. I'm talking about an 'ideal, perfect solution for an ideal,
perfect world' :-). ...

> > > Another issue is: is it really worth trying to hack libparted to
> > > do this?  I think (in principle, although the details haven't
> > > even been discussed yet...) that libparted will become part of
> > > LVMS, or something similar, in the distant future.  Options:
> > > * design an elegant (i.e. bloated) API to deal with the problem
> > > the Right Way.
> > 
> > This always my preferred solution to a problem. Keeping any
> > program/library modular is always the best way IMHO. This way it
> > creates less problems in the future ... although it requires more
> > changes in the present :-(
> 
> Go read http://www.jwz.org/doc/worse-is-better.html
> 
> The Right Thing TM doesn't always reduce problems in the future,
> because if you can't adapt your nice modular system to a new
> situation, you're stuffed...
> 
> Of course, what I'm getting at here is: when we support LVM and RAID
> (probably via LVMS), what Issues are we going to face?  Are they
> going to affect this?
> 
> eg: it may make sense to have a common abstraction for logical volumes
> (LVM-speak) and partitions...
> 
> (logical volumes need not be continuous, or even on a single disk.
> however, partitions seem to be a subset of logical volumes)
> 
> Should LVM be considered a type of "extended partition".  I think
> not, because you can have many physical volumes forming an LVM.
> OTOH, it might make sense to go the other way...
> 
> In fact, extended partitions (and LVM partitions) are really like
> nested disk labels, EXCEPT the nested disk label has an Intimate
> Relationship with parent (!) disk label.  It would be really cool
> if we could think of a way of nesting disk labels, and making it
> transparent to the user.

Yes, this would be a good solution ... currently there is no way of
properly nesting a disklabel within a partition except by hackign
the partition code ...

Thanks

Timshel

-- 
   Timshel Knoll <address@hidden>  for Debian email: <address@hidden>
    Second year Computer Science, RMIT   |   CS108 Tutor (Semester 2, 2000)
        Debian GNU/Linux developer, see http://www.debian.org/~timshel/
   For GnuPG public key: finger address@hidden or address@hidden

pgp4KpaqE8AMU.pgp
Description: PGP signature