bug-parted
[Top][All Lists]
Advanced

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

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


From: Timshel Knoll
Subject: Re: Hacking parted to work with BSD disklabels ...
Date: Mon, 23 Oct 2000 23:44:32 +1100
User-agent: Mutt/1.2.5i

On Mon, Oct 23, 2000 at 06:25:04AM +1100, Andrew Clausen wrote:
> > Both :). The problem is that a BSD disklabel can be used in two ways.
> > The first (and most common on ix86 boxen) is to have the BSD partition
> > housed within a dos primary partition, ie. a type of `extended' partition.
> > The second is to have the disklabel used as the main partition table
> > for the disk, much like a `traditional' partition table (this is usually
> > called 'dedicated' style. The problem is that I'll have to do one of a
> > number of things:
> >  - only use support for 1 use of the disklabel at this stage (not good)
> >    (I've coded quite a bit of this - for only the 'dedicated' disklabel)
> >  - lots of code duplication to get it working for both (also not good)
> >  - somehow create a nasty hack that works around both solutions
> >    (can't think of a way to do this)
> >  - Other ideas that I haven't come up with yet :-)
> 
> You do realise that 1.4.x allows disk-label specific metadata (both
> per-disk and per-partition)?  You could have a BSD field inside the
> MSDOS specific metadata for this.

Hmmmm ... I noticed that but didn't really look properly at what it
does - oh well more code reading to do ;-)

> For RAID and LVM, I've used the partition flag system, rather than
> file system types.  I guess it would make sense to do that for
> BSD as well (i.e. make a PED_PARTITION_BSD flag)
> 
> Maybe.  But, it seems you can have data partitions inside BSD
> partitions (sort of like extended partitions), etc.

Yes.

> How do you envisage Parted (the front end) interfacing this kind
> of stuff?  I'm scared!  Having more than one extended partition
> would require a fair bit of code to change... and the general
> case gets much more difficult...
>
> (/me has nightmares about alignment and metadata allocation)
> 
> One (yucky) option might be to allow users to create a BSD
> partition (say, /dev/hda3), and then do:
> 
>       (parted) select /dev/hda3
> 
> To edit it, as if it is it's own block device.  This will probably
> break, though, if *anything* is expressed in terms of the entire
> /dev/hda (not just /dev/hda3).

Yes, I noticed that the extended/logical partition scheme is embedded
within a lot of code in disk.c etc ....
This is a problem I've come across. The method I thought of
is not to use a 'select' command, but to add 2 new partition types:
bsdlabel (or similar) and bsdpart. This still leaves us with a fairly
major problem - I believe that it is a valid configuration to have
2 (or more) BSD disklabels on the one disk - since *BSD refers to
partitions/labels using a partition (slice, in BSD-ish) number and
a letter indicating the sub-partition, ie:
/dev/ad1s3a
specifies the first sub-partition (a) in the disklabel on the 3rd
disk slice (partition) (s3) on disk ad1 (hdb in linux-speak).

> > > BTW: I don't know much about BSD slices... are there any good docs,
> > > or readable code I can look at?  It's hard for me to comment, until I
> > > know what I'm talking about ;-)
> > 
> > OK, check include/linux/genhd.h for some basic info on the internals ...
> > struct bsd_disklabel is the actual disklabel, and is found at sector
> > 1 in the partition that the disklabel is found in.
> 
> I'm sure I said "readable"... :-P

:) I didn't find the kernel code _that_ bad ... if you want the actual
partition reading code, check out linux/drivers/block/genhd.c (on 2.2.x)
or linux/fs/partitions/msdos.c on 2.[34].x

> Yoshi's link is pretty good though...

I'll have to check it out then :-)

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

Attachment: pgpe0NWktW0uP.pgp
Description: PGP signature


reply via email to

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