Bug 255799 - ffs crash on ufs file system
Summary: ffs crash on ufs file system
Status: Closed Not A Bug
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 13.0-RELEASE
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-fs (Nobody)
Depends on:
Reported: 2021-05-11 18:29 UTC by doctor
Modified: 2021-06-19 20:34 UTC (History)
2 users (show)

See Also:

core file (289.04 KB, text/plain)
2021-05-11 18:29 UTC, doctor
no flags Details
info file (520 bytes, text/plain)
2021-05-11 18:29 UTC, doctor
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description doctor 2021-05-11 18:29:18 UTC
Created attachment 224856 [details]
core file

on 3 occasion I have seen 3 crashes in FFS on a UFS system on 3 separate occasions.
Comment 1 doctor 2021-05-11 18:29:54 UTC
Created attachment 224857 [details]
info file

vmcore.1 file in 1.1GB
Comment 2 Kirk McKusick freebsd_committer 2021-05-11 23:14:54 UTC
What were the details on the filesystem in question (df information, and ideally the first 100 lines of dumpfs of the filesystem). Were you running it using soft updates or journalled soft updates?

Were there any I/O errors reported for the drive in the system logs.

Did you run fsck on it after the crash, and if so what if any errors did it report/fix?

If you were running your filesystem with journalled soft updates, please try running a full fsck check on it (fsck -f). A drawback of any journalling filesystem is that it only checks things that it thinks might be wrong. If a disk error occurs, then unexpected data can get corrupted and a journal rollback will not fix it. Only a full check of the filesystem will do so. And as long as it is not fixed, you will keep tripping over the same error/panic until you do fix it.
Comment 3 doctor 2021-05-12 04:02:56 UTC
default so I think journaled soft updates. 

Apart from the fsck -f what else would you like me to run?
Comment 4 Kirk McKusick freebsd_committer 2021-05-12 20:32:02 UTC
(In reply to doctor from comment #3)
Please disable journalled soft updates. For example if you are running on disk /dev/ada0p2 on /mnt you disable journaling and check the filesystem using:

# unmount /mnt
# tunefs -j disable /dev/ada0p2
Clearing journal flags from inode 4
tunefs: soft updates journaling cleared but soft updates still set.
tunefs: remove .sujournal to reclaim space
# fsck -f -y /dev/ada0p2
# mount /dev/ada0p2 /mnt
# rm -f /mnt/.sujournal

Please capture the output of running the above commands. And once you have
made these changes let me know if you have any more "dup allocation" panics.
Comment 5 doctor 2021-06-18 14:14:37 UTC
I think I just when into single user mode,

ran fsck -y about 3 times and
forced the problem to correct itself.
Comment 6 Kirk McKusick freebsd_committer 2021-06-19 20:34:44 UTC
(In reply to doctor from comment #5)
Thanks for the update. The crashes that you got were because the filesystem was inconsistent. Once cleaned up by fsck they have gone away. Unfortunately, we have no way of marking the filesystem as needing a full fsck when one of these crashes has happened since the system has come to a halt.