On Wed, 26 Jan 2005, Terry R. Friedrichsen wrote:
> Is anybody besides *me* having file system corruption problems with
> FreeBSD 5.3? I've looked around on several of the mailing lists and
> found no men- tion of this.
>
> I have two different platforms on which I'm trying to run FreeBSD 5.3.
> One is an x86 SMP system (dual AMD Athlon 1900+) and the other is an
> Alpha DS-10.
Could you try setting the following setting in /etc/rc.conf:
background_fsck="NO"
Soft updates is supposed to trickle meta-data changes to the disk 'in
order' so that background fsck can make strong assumptions about the
consistency of data even after a crash. If these assumptions are being
violated -- hardware issues, a bug in the storage driver, gamma radiation
from on high, file system bugs, etc, cascading corruption may be possible.
While there were many reports of this early in bgfsck development, almost
all reports have gone away, with most of the remaining problems being put
down the hardware failure. However, it could be you've run into one.
Switching to always using foreground fsck should increase the reliability
of the scanning process, and result in an early "stop" if there's
unrecoverable corruption that fsck can recognize (it's more rigorous and
can handle more failure modes because plain fsck operates under weaker
assumptions).
Since this seems to be a reproduceable problem, the next step if we can
isolate it a bit (and get it caught before catastrophic failure), is to
generate some log information about the nature of the corruption as
reported by fsck. Typically this is done by reproducing the corruption,
booting to single user mode, and then logging "fsck -y" output to a memory
disk, booting multi-user, and e-mailing the fsck output to Kirk. :-) So
try switching to foreground fsck (which will slow the boot process), and
let's see if this prevents nastier corruption.
Begin the process by doing a full manual fsck of all file systems from
single-user mode to make sure we start out in a known good state. Don't
use "-p", as that will force the fsck to really look, not assume the
"clean" flag is right.
Thanks,
Robert N M Watson
>
> On the SMP system, doing anything I/O intensive (like a kernel build) quickly
> corrupts the file system - I start to encounter problems like being unable to
> remove entire directory trees because the system thinks that empty directories
> are not *really* empty and therefore cannot be deleted. Other problems occur,
> too.
>
> On the Alpha system, I'm trying to get Xorg to work, with no success. What
> normally happens is that the system locks up *totally* either when trying to
> configure X or when running the X server after configure generates a config
> file (I'm trying multiple versions of Xorg).
>
> The lockup means that I have to power-cycle the system to reboot. When I do
> this, the filesystem is *always* horribly damaged. I finally gave up when I
> couldn't even get into "sh" in single-abuser mode because /libexec/ld.so.1
> was no longer there ...
>
> What I'm going to try next is pulling one CPU out of the SMP system to see if
> that helps. On the Alpha, I'm just going to give up on Xorg for a while.
>
> I'd hate to have to drop back to 4.10 or 4.11 ...
>
> If anyone has any suggestions, or even just sympathetic words, I'd be happy
> to hear them!
>
> Thanks.
>
> Terry R. Friedrichsen
>
> [EMAIL PROTECTED]
> _______________________________________________
> freebsd-questions@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
