Ok, with Steve's help I think we're getting this narrowed down. There
seem to be 2 issues:
1) umounting snapshot causes I/O error & filesystem shutdown
2) subsequent oops
The first seems to be that when quota is enabled, _mount_ causes a
transaction via xfs_qm_mount_quotas. Now the log is dirty, it must be
flushed on umount, but we're ro -> error -> shutdown.
The second seems to follow from the first, if after this error LVM frees
a buffer that pagebuf subsequently wants to free again, things fall
down. We've seen the oops in various unrelated places. Not as clear on
this one yet, but I'll try error injection over an LVM volume and see
what happens. But if we can fix the first problem, the second will go
away in this _particular_ case. :)
FWIW, I have not seen any compiler dependency for this problem yet...
On Wed, 2002-02-27 at 16:40, FORRESTER,JUSTIN (HP-Loveland,ex1) wrote:
> I've got some more info about the umount oops that might be helpful. It
> looks like what is happening in our case is the following:
> - overflow a LVM snapshot
> - in response, LVM *de-activates* the logical volume for the snapshot, such
> that subsequent write attempts cause I/O errors
> - XFS attempts to write log information, gets the I/O error, and shuts the
> filesystem down.
> - something is corrupted at this point, such that writes to a *different*
> XFS filesystem result in the kernel oops. In our case this is when umount
> writes to /etc/mtab, which is not even on an LVM volume.
> I've included some log information below that substantiates this theory.
Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs
sandeen@xxxxxxx SGI, Inc.