Date: Thu, 12 Feb 2004 13:20:12 +0100 From: Matthias Andree <ma@dt.e-technik.uni-dortmund.de> To: Scott Long <scottl@freebsd.org> Cc: Matthias Andree <ma@dt.e-technik.uni-dortmund.de> Subject: Re: AIC7XXX (2940UW Pro) file system corruption Message-ID: <m3bro4h4lf.fsf@merlin.emma.line.org> In-Reply-To: <402AF528.8020109@freebsd.org> (Scott Long's message of "Wed, 11 Feb 2004 20:38:16 -0700") References: <m3smhhj02k.fsf@merlin.emma.line.org> <402AF528.8020109@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Scott Long <scottl@freebsd.org> writes: >> Feb 6 20:10:20 libertas /kernel: swap_pager: indefinite wait buffer: device: #da/0x20001, blkno: 4296, size: 24576 > > There is a very good chance that your disk is going bad. The dump card > states are due to the disk not responding to commands within the timeout > period. Hmmm... what this does not yet explain is the massive corruption that my /var file system (softdeps) suffered and that fsck -p wouldn't fix. As the drive was running with WCE:0 at the time it crashed, can we assume that the drive hasn't reordered writes? If we can, then there is a massive problem with the softupdates write ordering that the disk sees, either blocks being scheduled in the wrong order or ordered tags (as write barriers that prevent reordering) missing. I don't know how responsibilities for maintaining ordering requirements are split in FreeBSD 4 currently, but if softupdates-ffs claims it maintains an on-disk image that is always consistent no matter when the machine crashes, and drive configuration allows for the loss of exactly 1 block, then something is really wrong. -- Matthias Andree Encrypt your mail: my GnuPG key ID is 0x052E7D95
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m3bro4h4lf.fsf>