Message-Id: <200102231303.f1ND3mW29942@jen.americas.sgi.com>
To:     "Irresponsible & Crazy" <linux-xfs@jeremi.pl>
cc:     linux-xfs@oss.sgi.com
Subject: Re: Hardware fault intolerance... 
In-Reply-To: Message from "Irresponsible & Crazy" <linux-xfs@jeremi.pl> 
   of "Thu, 22 Feb 2001 14:57:22 +0100." <1460.212.160.232.6.982850242.squirrel@mail.jeremi.pl> 
Date:   Fri, 23 Feb 2001 07:03:48 -0600
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Does anybody know how xfs handles "just appeared" badblocks? If even...
> How to inform xfs about badblocks (if that's possible) to let xfs avoid them
> or just kiss hdd goodbye
> 
> I took latest cvs snapshot (21.02.2001 18:00CET), made kernel and set vga=9
> to see whole Oops output and I think I know where exactly those bads hide on
> my hdd, I should have Oops in my next post if anybody interested...
> 
> Filip
> -- 
> "Oh shit! o shit! o shit! I'm gonna die! I'm gonna die!" - Rincewind
> 

A feature just went into XFS which is shutdown on error, which basically
means that if we get a metadata I/O error the filesystem gets shutdown,
all processes in the filesystem get errored out of their system calls,
and you get to type unmount somewhere.

This is all there is really, however, if the timing was correct, you have
that code, so clearly you found a case which is not covered by it. Oops
output would be useful, ideally building in kdb and using a serial console
line to capture the output would be even more useful (use the bt command
to get a stack trace). However, I realize setting up a serial console
is not always an option.

Steve