the current in-core master superblock, and fix them up if
they're incorrect. Move the code that writes the alternate
superblocks if (cvtlevel || doswap) into pass 5 for efficiency.
Reviewd by Charles Hannum, and used by me to fix up a curdled
file system.
Also, be a bit more conservative with the clean flag: don't mark the FS
clean when we know there may still be errors (user anserwed 'n' to
a question, or fsck says "you must rerun fsck").
Fix a bug in fsck_ffs where if a directory somehow develops a hole
(that is a block pointer that has a value of zero), fsck would give the
filesystem a clean bill of health, but the kernel would panic when
accessing the directory with the hole. Fsck now checks for holes
in directories. If found in preen mode, fsck fails. In manual
mode, it can be directed to shorten the directory to the beginning of
the hole. A more complete solution would be to allocate a block to fill
the hole. However, this is a lot more work for a `cannot happen' error,
so the extra effort seems unwarranted.
- added missing prototypes, and made local functions static
- removed parallel preening code; this is part of fsck(8)
- use printing utilities from fsck(8)
- Makefile does not make links to fsck and fsck.8
- removed -l maxparallel option. It has no meaning anymore.
semantics. now:
(1) dirty file systems will always be checked; nothing new there.
(2) if not '-f' clean file systems will _NEVER_ be checked,
i.e. they won't be checked even if -p isn't specified. This
allows one to 'fsck -p ; fsck' to preen, then clean up
anything that 'fsck -p' barfs on, without waiting for the
clean file systems to be checked again.
(3) if '-f' clean file systems will ALWAYS be checked. This
allows people to put 'fsck -fp' into /etc/rc on systems
where they're leery of the FS clean flag state, need
the extra reliability, and can afford time 'wasted'
in checks.
The assumption made here is that if a file system is marked clean, it
_IS CLEAN_, really, and shouldn't be checked unless fsck is explicitly
told to (with -f). This should be a valid assumption, but may not be in
the presence of file system bugs. Documentation updated to note '-f'.
or not. this allows you to use this fsck and... reboot your system;
otherwise it would inf-loop rebooting and marking the FS clean,
which would then mark the fs modified, cause a reboot, etc.
