> FreeBSD can make ufs partitions, and I believe the Hurd can run on > them, although I have only tried accessing ufs partitions from the > Hurd, not booting the Hurd from them.
The Hurd uses a ufs format that is mostly compatible with BSD, though I am not sure that the Hurd does the right thing with the newest BSD ufs format details if they have changed in recent years (it works with original 4.3BSD and 4.4BSD formats). > I have wondered how the Hurd handles passive translators on ufs > partitions, as ext2fs needs to be created with the -O hurd option > in order for passive translators to work. The need for this is so that e2fsck will know about the translator blocks. The situation is similar in ufs, but no BSD fsck that I know of knows to check for the Hurd's translator blocks. For both ufs and ext2fs, the Hurd uses the traditional format except for a couple of new inode fields (which occupy space that was unused in the traditional inode formats). The only one of these that involves any hair is the translator field: the Hurd allocates a disk block to hold a passive translator setting, and stores this block number in the inode's translator field. If fsck does not know about this field, it will decide that the block was not really in use and it will mark it for reuse (you will see a complaint "salvaging unused blocks not in allocation bitmap" or something along those lines). In the case of ext2fs, e2fsck checks the "creator os" field in the superblock (this is what "mke2fs -o hurd" sets) and when it's set to the hurd value it knows about the translator inode field and does the right thing. In the case of ufs, you need to use the Hurd's native fsck since that is the only implementation around that knows about the translator field (it would be easy to hack any current BSD system's fsck to grok it).
