UFS originated from BSD, and is used in various Unix flavors including Sun Solaris and NextStep / Mac OS X.

The different variations use block sizes of 512, 1024, or 2048 bytes, the latter one intended for CD media. The superblock is located some way into the device; disktype only checks at 8K at this time. There are four different magic numbers for different revisions of the structures. The file system can be little-endian or big-endian, depending on the architecture of the vendor.

A BSD disklabel is a partition map with some special quirks. While it was originally designed to cover a whole disk, PC-based BSD flavors usually put it inside a DOS partition (which they call slices to set them apart from the partitions defined by the disklabel).

There are 8 partition slots in a basic BSD disklabel, but not all of them are created equal. The slots are labeled with letters, starting with a. The first four have special meaning by convention. The a partition contains the root file system. It also contains the disklabel itself, which is possible since the UFS superblock only starts at 8K into the partition. The b partition is used for swap space. The c partition slot refers to the whole disk (or slice, if applicable), but has the type set to Unused (0). Finally, the d partition slot is completely unused. The remaining slots are used for additional file systems, e.g. /usr or /var.

One more quirk is that the disklabel uses absolute sector numbers, even if it lives inside a DOS slice. As if that wan't enough, FreeBSD adjusts that data on the fly if you access the device file for the slice. disktype tries to adapt to all situations by finding the lowest sector number used in the label.

disktype recognizes BSD disklabels by their magic number. Partitions that overlap with the disklabel itself are reported and analyzed in the right context. The data for the c partition is always reported, even if marked as unused.

At this time disktype only probes the beginning of the second sector and assumes a sector size of 512 bytes. Apparently, the placement of the disklabel is different on certain architectures. I would appreciate any additional information on this.

Like UFS, the System V file system originated in one of the "original" Unix strains and was adopted by many commercial flavors built on that code. The Linux kernel supports quite a few variants, including two with PDP-11 byte order. Unfortunately, some don't have a magic and thus can't be detected reliably. disktype supports the Xenix and the System V R2 and R4 variants.

Information on System V file systems can be found at http://www.knm.org.pl/prezes/sysv.html, the page for the Linux driver.

XFS is SGI's high-performance file system, originally developed for IRIX. Like JFS, it has been open-sourced and ported to Linux. XFS does meta-data journalling, and even has optional real-time features.

Unlike most Unix file systems, XFS puts the superblock at the very beginning of the device. All data is stored in big-endian byte order.

Information on the Linux port of XFS can be found at http://oss.sgi.com/projects/xfs/.

Solaris SPARC uses a disklabel in the BSD fashion. Unfortunately, I wasn't able to gather much information about it beyond the actual on-disk structure.

disktype detects the Solaris SPARC disklabel by its magic number. As usual, all partitions are listed and analyzed recursively.

Solaris x86 (or "Intel Platform Edition") uses a scheme similar to the PC BSDs. A single PC-style partition is set aside for Solaris, which is then sub-partitioned using a proprietary partitioning scheme. The scheme used in Solaris is known as VTOC. Like the BSD disklabel, it has a fixed number of slots, and some of them are allocated to fixed special purposes, like the root file system or the swap partition. There is also one entry that covers the whole PC-style partition, it is dubbed "overlap".

disktype detects the Solaris x86 disklabel by its magic number. As usual, all partitions are listed and analyzed recursively.