[Top] [All Lists]

Re: Segfault of xfs_repair during repair of a xfs filesystem

To: Arthur Corliss <corliss@xxxxxxxxxxxxxxxx>, Rainer Krienke <krienke@xxxxxxxxxxxxxx>
Subject: Re: Segfault of xfs_repair during repair of a xfs filesystem
From: Rainer Krienke <rainer@xxxxxxxxxxx>
Date: Sat, 10 Jan 2004 09:51:45 +0100
Cc: Eric Sandeen <sandeen@xxxxxxx>, linux-xfs@xxxxxxxxxxx
In-reply-to: <Pine.LNX.4.58.0401070632280.25685@xxxxxxxxxxxxxxxxxxxxxxxx>
References: <Pine.LNX.4.44.0401060834240.16654-100000@xxxxxxxxxxxxxxxxxxxxxx> <200401071135.12886.krienke@xxxxxxxxxxxxxx> <Pine.LNX.4.58.0401070632280.25685@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: KMail/1.5.4
Am Mittwoch, 7. Januar 2004 16:42 schrieb Arthur Corliss:
> On Wed, 7 Jan 2004, Rainer Krienke wrote:
> > In between I contacted the vendor of the hardware IDE raids. The
> > technician confirmed that these raids have a read/write cache and that
> > there is *no* battery backup. So in case of an active filesystem where
> > suddenly there is a powerfail, it is likely that the hardware cache in
> > the raid is not written to disk and the filesystem will be become
> > inconsitent. And this very probably happened in my case.
> >
> > So the remaining question is only why xfs_repair was unable to repair the
> > damaged filesystem....
> If I had to hazard a guess, I'd think that the transaction log, being hit
> much more frequently than most other portions of the filesystem, would be
> much more aggressively cached by the hardware's algorithms, which would
> leave the log that much more inconsistent than the filesystem.  *That*
> can't help during repairs. . .
> In any event, it sounds like you need a UPS on that system now, eh?

In between we found another possibility. Our vendor told us that now there is 
a firmware upgrade that allows the write cache to be disabled. So we are 
probably going to do this, to get rid of this problem. 


Attachment: pgpH0amleqoGJ.pgp
Description: signature

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