xfs
[Top] [All Lists]

Re: Segfault of xfs_repair during repair of a xfs filesystem

To: Rainer Krienke <rainer@xxxxxxxxxxx>
Subject: Re: Segfault of xfs_repair during repair of a xfs filesystem
From: Greg Freemyer <freemyer-ml@xxxxxxxxxxxxxxxxx>
Date: Mon, 12 Jan 2004 10:08:17 -0500
Cc: Arthur Corliss <corliss@xxxxxxxxxxxxxxxx>, Rainer Krienke <krienke@xxxxxxxxxxxxxx>, Eric Sandeen <sandeen@xxxxxxx>, linux-xfs@xxxxxxxxxxx
In-reply-to: <200401100951.52922.rainer@xxxxxxxxxxx>
References: <Pine.LNX.4.44.0401060834240.16654-100000@xxxxxxxxxxxxxxxxxxxxxx> <200401071135.12886.krienke@xxxxxxxxxxxxxx> <Pine.LNX.4.58.0401070632280.25685@xxxxxxxxxxxxxxxxxxxxxxxx> <200401100951.52922.rainer@xxxxxxxxxxx>
Reply-to: freemyer-ml@xxxxxxxxxxxxxxxxx
Sender: linux-xfs-bounce@xxxxxxxxxxx
On Sat, 2004-01-10 at 03:51, Rainer Krienke wrote:
> 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. 
> 
> Thanks
> Rainer

If you care much about performance, you will need to re-do any
benchmarking or other performance testing after the change.

I was testing our restore procedure recently for xfs filesystems.  I
found a tremendous speed difference between restoring with write cache
enabled/disabled.  (iirc, 300% or so)

fyi: I was using tar, not xfs_restore.

Greg
-- 
Greg Freemyer


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