tech-kern archive

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

Partitions on empty disk{s,images}

I recently fixed an atf test case that did expect to find an "a" partition
afer configuring a vnd with an image just created by dd'ing from /dev/zero.

In general for disk devices the partition is mapped to the minor device
number, which by its very nature is a device specific concept. If anyone
still remembers floppy disk drives: on i386 (back then) we used them
to tell the driver about the media size:

     The driver supports the following floppy diskette formats by using
     particular partitions:
           1.44MB 3.5-inch (b)
           1.2MB  5.25-inch (c)
           360KB  5.25-inch (1.2MB drive) (d)
           360KB  5.25-inch (IBM-PC drive) (e)
           720KB  3.5-inch (f)
           720KB  5.25-inch (g)
           360KB  3.5-inch (h)

On sparc the list was different:
     Bits [0-3] of the minor device number of the special files referring to
     this device encode the floppy density as follows:

           0       3.5'' 1.44MB floppy diskettes.
           1       3.5'' 720KB floppy diskettes.
           2       3.5'' 360KB floppy diskettes.
           3       3.5'' 1.2MB/NEC Japanese format floppy diskettes.

Now for hard disks this is a bit different and we map slices to minor
numbers (so wd0a is the first partition, wd0b the second, ...),
unless we are using wedges (where we just have dk0, dk1, ...).

Partition information used to be stored in machine dependend ways (to make
it easier to cooperate with other operating systems on the same disk),
so x86 machines still know about fdisk (DOS) partition tables, sparcs know
about sun labels.

With USB sticks and GPT this all became questionable. Nowadays we do not warn
about a disk w/o a disklabel (it could be a USB stick brought over from
your camera). And we started to unify/centralize code that reads partition

Sorry for the long excurse, now back to the original issue at hand:

If I do:

   dd if=/dev/zero of=./disk.img bs=1m count=20
   vnconfig -c vnd0 ./disk.img
   disklabel vnd0

what should I expect to see?

Currently I can only expect a raw partition (that is: sysctl kern.rawpartition
translated to a..z) to cover the whole disk.

Some ports (like x86, or maybe all MBR using ports) create an 'a' partition
of the full image size, conveniently typed ffs, so you can just go ahead
and newfs it.

It may be good to have a common rule about this, and if so add tests to verify.

So: should we expect an 'a' partition on a disk that is fully zeroed?


P.S.: I have not verified, but I guess this all started with me changing
the sunlabel code to not return an error if no disklabel was found, as I
am now using increasingly more GPT labeld disks and wanted to get rid of
the nasty warnings. Maybe I did something wrong in that change - if so,
another reason to have reasonable tests.

Home | Main Index | Thread Index | Old Index