AI can presently create fdisk(1m) partitions of several different DOS/FAT types.
Since mkfs(1m) can provide quick formatting, installing DOS/FAT file systems can be supported fairly easily. One method of doing so is almost completely transparent: if Target Instantiation creates a new DOS/FAT partition, it can also launch mkfs to lay down the file system. http://defect.opensolaris.org/bz/show_bug.cgi?id=6854 http://cr.opensolaris.org/~wmsch/bug-6854/ mkfs_pcfs(1m) allows the FAT entry size to be specified, and this value can be assumed from the partition type. fdisk formatting supported here: ID "DOS16" DOSOS16 "DOSOS16 16-bit FAT" ID "FAT32" FDISK_WINDOWS "FDISK_WINDOWS 32-bit FAT <2047GB" ID 12 FDISK_EXT_WIN "FDISK_EXT_WIN 32-bit FAT (extended-int13)" According to the man page for mkfs_pcfs, DOS drive letters are assigned in the order of the DOS partitions in the fdisk format table. mkfs -F pcfs -o fat=<# bits> /dev/rdsk/ctdp:<drive letter> Additional code in disk_parts.c was added to handle a bug in the case where: - a partition is to be deleted - partitions after that partition are to be preserved There is still a remaining problem: the determination of the drive letter does not seem to be as predictable as indicated in mkfs_pcfs(1m). In particular, if DOS partition types are mixed, the drive letter assignment does not occur as documented. This can be a hazard since the wrong partition may be formatted. This problem is documented further in bug 6854 For now, I think that this should be treated as either a problem with Solaris logical drive assignment, or should require a bug to be filed for AI for this rather unusual case. Tested: creating multiple using AI deleting using AI, then recreating using AI deleting some (not all) using AI, then recreating using AI not creating any new to check if formatting is done regardless if partition is old or new creating, varying # FAT bits testing all supported types William
