>> Anyone know the disk tab entry for the following drive?
>>
>>    M2266S-512    FUJITSU
>
> You shouldn't need a disktab entry to use the disk.  From memory,
> I usually do something like:
>
>	[ ... generate a template and edit as wish ...]

There is no need to have /etc/disktab entry to put disklabel, as Simon
mentioned, and a bit impractical to maintain /etc/disktab for all
possible disks.  diskpart(8) is one of old remainings NetBSD still
has.

A bit of history here; long time ago UNIX had no (modern) disklabel on
each disks.  The disk geometory and how the entire space is partioned
are maintained disk _drivers themselves_.  That's ok because any UNIX
users have the entire UNIX source code and were expected to have
abilities to compile and build the whole world of UNIX. 

This started being pains for the computer makers which wanted to sell
their products as so-called binary-only releases.  It's cumbersome to
support new types disk drives, too.  The solutions varied.  ULTRIX
lifted particular implementation dependencies and parameters out of
source code logics, and put the separate *.c files (See /sys/data/
directory if you have DU/Tru64 UNIX).  Some venders followed the
approach (a Japanese publishing company named ASCII once sold their
own port of 4BSD system and took the similar solution as ULTRIX did).

The approach was handicapped by the assumption of compiler ablability.
Others took a different solution encapsulating disk geometory and
partition information into _disk drives themselves_.  This is
handsomely benefitial to swap/reorder disk drives, too.  Then,
proprietry disklabel flowerlished in incompatible ways.

4.3BSD Tahoe approached the disklabel issue, and the resulting is what
we see those days.  Some computer makers, mostly which had BSD
derivatives like OSF/1 and Mach as well as vanilla 4BSDs, incorporated
Tahoe disklabel in their products.

Tohru Nishimura