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.
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.