[Bug 293244] ufs: crash involving (non)existant file

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293244

--- Comment #2 from Robert Clausecker <[email protected]> ---
(In reply to Kirk McKusick from comment #1)

I don't know.  jrtc27 mentioned having had a similar error following a system
crash.
I too had a system crash (had to do a hard reboot after running out of swap
space, leaving the system inoperable), so there could be something wrong with
the SU+J logic.  The file system has the default options set:

# tunefs -p /dev/ada0p2
tunefs: POSIX.1e ACLs: (-a)                                disabled
tunefs: NFSv4 ACLs: (-N)                                   disabled
tunefs: MAC multilabel: (-l)                               disabled
tunefs: soft updates: (-n)                                 enabled
tunefs: soft update journaling: (-j)                       enabled
tunefs: gjournal: (-J)                                     disabled
tunefs: trim: (-t)                                         disabled
tunefs: maximum blocks per file in a cylinder group: (-e)  4096
tunefs: average file size: (-f)                            16384
tunefs: average number of files in a directory: (-s)       64
tunefs: minimum percentage of free space: (-m)             8%
tunefs: space to hold for metadata blocks: (-k)            6400
tunefs: optimization preference: (-o)                      time
tunefs: volume label: (-L)                                 

It could also be that the consumer grade SSD I use in there does not correctly
order writes, causing an inconsistent state.

That said, following fsck -f, the error no longer reproduces.

Would it perhaps be possible for the system to handle this sort of corruption
more gracefully, avoiding a kernel panic?

-- 
You are receiving this mail because:
You are the assignee for the bug.