View Single Post
Old 17th June 2009
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

No dump was taken, or, there was a failure of a dump to disk when attempted by the kernel.

Your dmesg may have been retained in memory during reboot. If so, examine the output from dmesg(8) it to see if the dmesg contains any indicative kernel messages from the time of the reboot.
Quote:
the crash happened late in the afternoon, so it is not likely related to the fsck.ext2 which started before eight in the morning
I don't think you can discount it. For big file systems, running an fsck takes both tons of memory and tons of time.
Quote:
Originally Posted by FAQ 14.7, highlights in red are mine
fsck(8) time and memory requirements

Another consideration with large file systems is the time and memory required to fsck(8) the file system after a crash or power interruption. One should not put a 120G file system on a system with 32M of RAM and expect it to successfully fsck(8) after a crash. A rough guideline is the system should have at least 1M of available memory for every 1G of disk space to successfully fsck the disk. Swap can be used here, but at a very significant performance penalty, so severe that it is usually unacceptable, except in special cases.

The time required to fsck the drive may become a problem as the file system size expands, but you only have to fsck the disk space that is actually allocated to mounted filesystems. This is another reason NOT to allocate all your disk space Just Because It Is There. Keeping file systems mounted RO or not mounted helps keep them from needing to be fsck(8)ed after tripping over the power cord.

Don't forget that if you have multiple disks on the system, they could all end up being fsck(8)ed after a crash at the same time, so they could require more RAM than a single disk.

By the time one gets to somewhat larger than 1TB file system with default fragment and block sizes, fsck will require 1GB RAM to run, which is the application limit under OpenBSD. Larger fragments and/or blocks will reduce the number of inodes, and allow for larger file systems.
Reply With Quote