Bugs in fsck(8) and fsck_ufs(8)

[Perry Hutchison]

Polytropon <freebsd at edvax.de> wrote:
> On Sun, 12 Feb 2017 19:09:59 -0800, Perry Hutchison wrote:
> > I have a UFS filesystem that will not mount, and it confuses fsck(8):
> > 
> > # mount /dev/da2p2 /mnt
> > mount: /dev/da2p2 : Operation not permitted

> > ... fsck_ufs(8) also has trouble with this filesystem:  it
> > claims something is wrong, but it doesn't even identify any
> > specific problems much less fix them:
> > 
> > # fsck_ufs /dev/da2p2
> > ** /dev/da2p2
> > ** Last Mounted on /mnt
> > ** Phase 1 - Check Blocks and Sizes
> > ** Phase 2 - Check Pathnames
> > ** Phase 3 - Check Connectivity
> > ** Phase 4 - Check Reference Counts
> > ** Phase 5 - Check Cyl groups
> > 13527 files, 628739 used, 43580 free (236 frags, 5418 blocks,
> > 0.0% fragmentation)
> > 
> > ***** FILE SYSTEM STILL DIRTY *****
> > 
> > ***** PLEASE RERUN FSCK *****
>
> Do you have journaling enabled with UFS for that file system?

No, it is the UFS partition of a 10.3 installation memstick (with
a few additions, mostly small logfiles).

> Any other "non-standard" options which might be interfering?

Not that I know of.

> > So it seems this filesystem also provokes a bug in fsck_ufs(8):
> > any problem serious enough to not mark the filesystem as clean
> > is serious enough to at least report, if not fix.  (I've rerun
> > it several times, always getting the same result.)
>
> That indicates a severe problem with the file system.

Well, maybe -- but apparently not severe enough for fsck to report
it :(  and (I've since discovered) not severe enough to prevent
mounting the filesystem read-only.  After doing so I've looked
around and seen no obvious corruption.

> > I'd try falling back to lower-level tools, but it seems they no
> > longer exist:
> > 
> > # which icheck
> > icheck: Command not found.
> > 
> > # which dcheck
> > dcheck: Command not found.
> > 
> > # which ncheck
> > ncheck: Command not found.
> > 
> > Now what?
>
> A lower-level tool included with the OS is "fsdb".

Unless there is more to it than I noticed in the manpage, fsdb
might be useful in fixing an identified problem -- but it's not
at all clear how it would be much help in identifying a problem
that fsck_ufs(8) noticed but did not report.