[Top] [All Lists]

Re: Is it possible the check an frozen XFS filesytem to avoid downtime

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: Is it possible the check an frozen XFS filesytem to avoid downtime
From: Martin Steigerwald <ms@xxxxxxxxx>
Date: Wed, 16 Jul 2008 09:53:56 +0200
Cc: Timothy Shimmin <tes@xxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <487CC1EB.6030100@xxxxxxxxxxx>
Organization: team(ix) GmbH
References: <200807141542.51613.ms@xxxxxxxxx> <200807150944.13277.ms@xxxxxxxxx> <487CC1EB.6030100@xxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: KMail/1.9.9
Am Dienstag, 15. Juli 2008 17:27:39 schrieb Eric Sandeen:
> Martin Steigerwald wrote:
> > Okay... we recommended the customer to do it the safe way unmounting the
> > filesystem completely. He did and the filesystem appear to be intact
> > *phew*. XFS appeared to detect the in memory corruption early enough.
> >
> > Its a bit strange however, cause we now know that the server sports ECC
> > RAM. Well we will see what memtest86+ has to say about it.
> in-memory corruption could mean, but certainly does not absolutely mean,
> problematic memory.  It could be, and usually is, a plain ol' bug (in
> xfs or elsewhere).


Yes, I thought about this, too. But then the machine ran over one year without 
any visible issues. And it happened only on one server, not on the other. It 
happened on the server that does NFS tough... could be an NFS related issue 
then. The other one does MySQL with the database stored on a XFS volume, too. 
But there haven't been any visible issues.

Well we will see whether it happens again on the server that has taken over 
and is now doing both MySQL and NFS. If it does, I think we will update to 
one of the lastest Debian Etch backport kernels (2.6.24 or even 2.6.25) on 
one of the servers and see whether that helps.

Martin Steigerwald - team(ix) GmbH - http://www.teamix.de
gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90

<Prev in Thread] Current Thread [Next in Thread>