Date: Wed, 22 May 2002 08:36:15 -0500 (CDT)
From: Eric Sandeen <sandeen@sgi.com>
To: Michael Wahlbrink <x_miw@propack-data.com>
cc: linux-xfs <linux-xfs@oss.sgi.com>
Subject: Re: Still some corruption occurs on my root filesystem
In-Reply-To: <3CEB9B2F.9000703@propack-data.com>
Message-ID: <Pine.LNX.4.44.0205220823510.20749-100000@stout.americas.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Wed, 22 May 2002, Michael Wahlbrink wrote:

> > The only thing here is "normal" log recovery, nothing that should indicate
> > corruption.  I assume that this is after what claims to be a  clean shutdown?
> 
> So I can sleep now without thinking 'bout lost data.... ;-)
> Thanks!

Well... if you shut down your system cleanly, you should not be doing
recovery, so something is still not right (assuming that the messages
you posted were after a normal shutdown).

> > Probably the BLKSETSIZE ioctl, perhaps your raid driver doesn't implement
> > it?  I wonder if this could be part of the problem... at one point it looked
> > like this was harmless. 
> 
> 
> Ok, how to find out?? Should I forward/write something to the ataraid 
> ML?? I'm not a kernel hacker, so I dont have any glue what ioctls are ;-)

Whoops, a couple things.  first, it's "BLKBSZSET" that I was thinking about,
but I don't think you'd see this at boot time in any case.

It would be nice if the ataraid driver printed out _which_ ioctl was
unsupported...  in pdcraid.c you could change the

printk("Invalid ioctl \n");

line to

printk("ataraid: invalid ioctl cmd=%x %lx\n", cmd, arg);

if you wanted to chase this down, although I don't know if it's related
to your problem.

-Eric