Catching up on old mail..

On Tue, 1 Feb 2000, Bradley R. Smith wrote:

> I believe disklabel reports sizes in terms of sectors which are 512
> bytes each, exactly half of 1kb. The disklabel(8) man page doesn't
> appear to mention this or describe how to interpret the other fields
> either.=20

disklabel reports sizes in terms of sectors, which on most disk drives
happen to be 512 bytes long. On disks with 1k or 2k partitions, it reports
them interms of the relevant sector size.

> Where would I look for that kind of information?
> I've been reading the "The Design and Implementation of the 4.4 BSD OS" w=
here I learned about blocks, fragments, and cylinder groups in the Berkeley=
 Fast File System.
> I'm guessing that:
> fsize =3D fragment size in bytes
> bsize =3D block size in bytes
> cpg =3D cylinders per group?=20
 <from a netbsd-i386 disklabel; what's cpp in the mac68k one below?> > >

Yes, though these values only have meaning for FFS partitions. I think cpp
was a typo - it should be cpg.

> I'm also guessing that the reason that fsize and bsize are 0 in the
> disklabel below is because it's "fictitious."  :)  The mac68k port
> doesn't actually put a disklabel on the disk, right? Because it
> conflicts with MacOS somehow?=20

The reason they are 0's is not that the disklabel is ficticious, but
because we don't have a place in the MacOS partitions to store this info.=
=20

You'll get a ficticious disk label even off of an unformatted disk. If you
then edit it (on ports where you can) and write it out, it will keep the
disklabel type you had unless you change it. So most of them end up being
"ficticious". :-)

> On 2/1/00 at 15:49, Netzhaut@t-online.de (Dirk Hoppe) wrote:
> > followed. I was surprised about the partition size in disklabel. For ex=
ample
> > a: 102400, shouldn=B4t it be 51200 (50 MB)?

Right. They are 512-byte sectors, so 102400 is 51200 K. :-)

Take care,

Bill