Subject: Re: disks write-back cache
To: Patrick Welche <email@example.com>
From: Manuel Bouyer <firstname.lastname@example.org>
Date: 05/13/2003 22:19:06
On Thu, May 01, 2003 at 10:41:13PM +0100, Patrick Welche wrote:
> On Tue, Apr 29, 2003 at 08:55:48PM +0200, Manuel Bouyer wrote:
> > On Tue, Apr 29, 2003 at 09:31:54AM +0100, Patrick Welche wrote:
> > > I just replace the kernel with an old one, and have done another
> > > 3 successful make releases on that machine, so I really can't
> > > believe it's the disks which are at fault.. (With a new kernel
> > > the disklabel of one of the disks was even changed(!)) The best
> > > I can think of is that maybe the new ahc driver reorders commands
> > > more agressively? Is it possible? Does it expect the "yes I've
> > > written it" from the disk to be true?
> > No, the driver itself shouldn't reorder the commands. The drive may.
> > >
> > > Anyway, I'll try switching off write-back to see if that improves
> > > things, and then try switching off tagged queueing.
> > This would be a good test. I played a bit on sparc64, with 2
> > disks connected and couldn't reproduce the problem. But I only have a
> > plain 2940UW, which also worked fine with the old driver.
> > > I'm assuming
> > > it's safe to install a new fsck binary with an old (16th April)
> > > kernel to help patch up the disks after they have been messed up
> > > by the new kernel..
> > It should.
> And switching off write-back cache so far seems to have cured things..
> The story is:
> ahc write-back cache tagged queueing state
> old enabled enabled rock solid 24/7
> new enabled enabled creates corrupt files/fsck :(
> new disabled enabled make release succeeded
> So was I just lucky before?
I'm not sure how tagged queing was used by the old ahc driver. Maybe the
new one push the drive harder.
Manuel Bouyer <email@example.com>
NetBSD: 24 ans d'experience feront toujours la difference