There are various issues in how we refer to FFS versus UFS and the different versions (FFSv1, FFSv2), and this causes confusion and potential failure. Depending upon the feedback on these various issues, I'll raise PRs for each of them. 1. In general, there is inconsistenct of "UFS" and "FFS", including version variations such as "UFS1" versus "FFSv1", within documentation, command names, command output, (etc.) The source code organisation in src/sys/ufs implies a common code-base called "ufs", with more specific implimentations of "ffs" (Berkeley Fast File System), "ext2fs" (Linux ext2), "lfs" (Berkeley Log-structured File System), (etc.) Given existing tool names (newfs_ffs, ...), I argue that we should just standardize on referring to the file system as "ffs" in both command name and command output. 2. installboot(8) doesn't have the ability to confirm that the primary bootstrap (/usr/mdec/bootxx_FOO) matches the underlying file system that is being installbooted to. installboot(8) can already determine the file system type (based on magic numbers in the superblock, for example). However, there isn't an easy way to determine which file system a given primary bootstrap is implemented for. A hacky solution would be to check the suffix on the filename, but I dislike this. We should investigate a technique to encode details of which file system the bootstrap is for. This would most likely need to be a Machine Dependent (MD) solution, handled by a new method in usr.sbin/installboot/arch/*.c It could be implemented by encoding into the primary boostrap a descriptive text string or even just the magic number of the superblock of the target file system. 3. The dumpfs(8) manual doesn't adequately describe the differences between the different FFS versions (including the various file system levels of FFSv1), nor adequately explain the fields in the output of the command. This is partly related to point 5 below. 4. The dumpfs(8) output can be confusing when attempting to determine if a file system is FFSv2 (so that /usr/mdec/bootxx_ffsv2 is to be installboot(8)ed.) E.g, this is a FFSv2 file system; FFSv2 superblock, 256 byte inodes, support for files over 1 TiB: file system: /dev/rraid1a endian little-endian location 65536 (-b 128) magic 19540119 (UFS2) time Sat Mar 28 17:32:12 2009 superblock location 65536 id [ 47ec8809 7378477a ] cylgrp dynamic inodes FFSv2 sblock FFSv2 fslevel 5 This is an FFSv1 file system, FFSv1 superblock, 128 byte inodes, but with the "FFSv2 layout" of the FFSv1 superblock: file system: /dev/rraid0a endian little-endian magic 11954 (UFS1) time Tue Mar 31 20:10:03 2009 superblock location 8192 id [ 49cbf150 5cd4bfa3 ] cylgrp dynamic inodes 4.4BSD sblock FFSv2 fslevel 4 At first glance of the latter without the former for reference, a user will see "sblock FFSv2" and mistakenly assume that /usr/mdec/bootxx_ffsv2 is the primary bootstrap to install. (This is incorrect, and will result in an unbootable system.) I would like to rearrange the output slightly and make it clearer that this is an FFSv1 file system in the latter example and FFSv2 in the former. 5. fsck_ffs(8) doesn't describe the "fslevel 5" value of dumpfs(8). This is partly related to point 3 above. I know that "fslevel 5" in dumpfs(8) is actually just FFSv2 and that fsck_ffs -c can't convert from FFSv1 to FFSv2. 6. newfs(8) -O <filesystem-format> uses different values than fsck_ffs(8) -c <fslevel> This isn't a big deal, although an explanation of the relationship between the two in newfs(8) may be helpful. 7. We lack a ffs(7) manual page. FreeBSD has ffs(7) which may be a useful starting point. 8. Installation documentation, sysinst, NetBSD guide (etc.) will all need updating depending upon the result of this. cheers, Luke.
Description: PGP signature