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.
Attachment:
pgp9UZqvJZRVR.pgp
Description: PGP signature