Bill Studenmund wrote:

>To adapt, we need to make two sets of changes:
>
>1) We need to store the block, fragment, and Cylinder per group numbers.
>When I was at NASA, we made some 32k/4k file systems for performance. It
>was really helpful to be able to have those values stored in the
>disklabel. There are a number of unused bytes in the BlockZeroBlock, the
>bzb, which is space in the partition entry used by A/UX, NetBSD, and the
>linuxes. NetBSD uses a few more flags than do the linuxes.
>
We don't currently define all the areas of the A/UX extension of the map 
entry in our disklabel header.  When I did the sysinst/mac68k code I 
included the missing definitions and used some of them to store values 
during partitioning.  While it's not absolutely necessary that we 
preserve these areas for sysinst use, it might be nice. ;-)

The areas remaining in the A/UX extension that I didn't use are:
   the 8-bit cluster size
   the 16-bit inode bad block number
   the 8-bit unused/undefined part of the flags word
   the 5-bit slice number in the flags word, although this would be nice 
for OS type
           such that various BSD type systems could distinguish their 
partitions
   the three 32-bit time fields reserved for FS creation, mount and 
umount time.
          These might be good for block, fragment and Cyliner/group values
   none of the abm or filler reserved for the abm

NetBSD and/or sysinst/mac68k currently uses:
   the magic, type and root/usr/crit/part of the flags word and the 
mount_point name

>I propose we use some of the unused bytes off the end to store the needed
>values (which are a uint32_t, a uint16_t, and a uint8_t), and to add a
>flag indicating these values are valid. If any of the other OS's have used
>fields off the end, I'd like to make sure we don't stomp on them. :-)
>
>2) We need to be able to describe more than just an ffs. NetBSD has 21
>different partition type codes which can live in a disklabel. I think that
>very few of them make sense for an Apple partitioned disk. Certainly the
>historical ones (V6, V7, SystemV, etc.) don't make sense. Nor do I think
>AmigaDOS, FILECORE, NTFS, and the OS/2 fs make sense. :-)
>
>The ones which definitly need support are lfs, ccd, and raid.
>
>There are two ways we could do this. One would be to make NetBSD_LFS,
>NetBSD_CCD, and NetBSD_RAID partition names. Another would be to add one
>new NetBSD partition type, and have the partition type code stored in
>there.

We could just extend the meaning of the type field.  Right now only the 
first three values are defined: 1 =>Std FS; 2=>Autorecovery (not used); 
3=>SWAP.  This is an 8-bit field so we have 253 values not yet defined.

However, I'd like to propose that we define a new structure that we tuck 
into the area reserved for ABM expansion.  This area contains room for 7 
32-bit words and should be more that enough for what we need.  That way 
if anyone or anything chooses to use the other already defined fields 
that we don't we shouldn't have any conflicts.  If we feel we need more 
room we could take the three 32-bit words currently reserved for the abm 
itself giving us a total of 10 contiguous words.

-bob