uname -srmpK
FreeBSD 13.2-RELEASE-p2 amd64 amd64 1302001


After a problem with a hard disk drive or the controller (SAS2008 via mps) it was necessary to power off the machine.
When the machine ran again, I performed a file system (UFS2) check with fsck_ffs.


The following was executed as a non-root user:

fsck_ffs -d /dev/ufsid/5ba7d4b60a5f1bc2
** /dev/ufsid/5ba7d4b60a5f1bc2 (NO WRITE)
bad size: blk 1087831824, offset 0, size 15
Segmentation fault


Again, but with GDB:

gdb fsck_ffs
GNU gdb (GDB) 13.1 [GDB v13.1 for FreeBSD]
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd13.1".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from fsck_ffs...
Reading symbols from /usr/lib/debug//sbin/fsck_ffs.debug...
(gdb) run -d /dev/ufsid/5ba7d4b60a5f1bc2
Starting program: /sbin/fsck_ffs -d /dev/ufsid/5ba7d4b60a5f1bc2
warning: Could not load shared library symbols for [vdso].
Do you need "set solib-search-path" or "set sysroot"?
** /dev/ufsid/5ba7d4b60a5f1bc2 (NO WRITE)
bad size: blk 1087831824, offset 0, size 15

Program received signal SIGSEGV, Segmentation fault.
Address not mapped to object.
0x000000000103aba9 in checksnapinfo (snapip=0x7fffffffe2c8) at /usr/src/sbin/fsck_ffs/setup.c:332
332	/usr/src/sbin/fsck_ffs/setup.c: No such file or directory.


I made this change:

diff --git a/sbin/fsck_ffs/setup.c b/sbin/fsck_ffs/setup.c
index f06424558cf4..a67707c08c26 100644
--- a/sbin/fsck_ffs/setup.c
+++ b/sbin/fsck_ffs/setup.c
@@ -319,6 +319,8 @@ checksnapinfo(struct inode *snapip)
        size = fragroundup(fs,
            DIP(snapip->i_dp, di_size) - lblktosize(fs, lbn));
        bp = getdatablk(idesc.id_parent, size, BT_DATA);
+       if (bp->b_errs != 0)
+               return (0);
        snapblklist = (daddr_t *)bp->b_un.b_buf;
        /*
         * snapblklist[0] is the size of the list


Executed again with the now changed fsck_ffs:

fsck_ffs -d /dev/ufsid/5ba7d4b60a5f1bc2
** /dev/ufsid/5ba7d4b60a5f1bc2 (NO WRITE)
bad size: blk 1087831824, offset 0, size 15
Removing non-snapshot inode 4 from snapshot list
SETTING DIRTY FLAG IN READ_ONLY MODE

UNEXPECTED SOFT UPDATE INCONSISTENCY
** Last Mounted on /data
** Phase 1 - Check Blocks and Sizes
INCORRECT BLOCK COUNT I=4 (2874176 should be 2877376)
CORRECT? no

INCORRECT BLOCK COUNT I=103459176 (8 should be 0)
CORRECT? no


Many problems where successfully repaired during this fsck_ffs run.

I don't know if the patch does the correct handling of this situation.
After a few completed runs with the unpatched fsck_ffs, the file system shows no signs of problems.