Bugs in fsck(8) and fsck_ufs(8)

Perry Hutchison perryh at pluto.rain.com
Mon Feb 13 03:11:14 UTC 2017

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 /dev/da2p2
fsck: Could not determine filesystem type

Why can't fsck(8) recognize the filesystem type?  file(1) has no
trouble (lines wrapped):

# file -s /dev/da2p2
/dev/da2p2: Unix Fast File system [v1] (little-endian),
last mounted on /mnt, last written at Sat Jan  7 18:18:40 2017,
clean flag 0, number of blocks 674416, number of data blocks 672319,
number of cylinder groups 13, block size 8192, fragment size 1024,
minimum percentage of free blocks 8, rotational delay 0ms,
disk rotational speed 60rps, TIME optimization

To be outdone by file(1) in filesystem type recognition is pretty
clearly a bug in fsck(8), but not a terribly serious one since it
can be gotten around easy enough by running fsck_ufs(8) directly.
However, 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)



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.)

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?

More information about the freebsd-questions mailing list