Created attachment 224856 [details]
on 3 occasion I have seen 3 crashes in FFS on a UFS system on 3 separate occasions.
Created attachment 224857 [details]
vmcore.1 file in 1.1GB
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.
default so I think journaled soft updates.
Apart from the fsck -f what else would you like me to run?
(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.
I think I just when into single user mode,
ran fsck -y about 3 times and
forced the problem to correct itself.
(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.