Steve,
Thanks for the quick response.
> In this case I have no idea - if you are not running on an xfs
> filesystem then this has nothing to do with xfs, there are no mods in
> the code base which would get executed in this case.
>
> I suspect the forced shutdown code in xfs is going to need some work
> before this scenario will work for you. You could try editing the
> _xfs_force_shutdown() function in fs/xfs/xfs_rw.c and removing this
> chunk of code:
>
> while (xfs_incore_relse(&mp->m_ddev_targ, 1, 0)) {
> if (ntries >= XFS_MAX_DRELSE_RETRIES)
> break;
> delay(++ntries * 5);
> }
>
> What it is doing in there looks radically different from the Irix
> version, and is I suspect broken in this case. Let me know what this
> does for you.
I made this change, and the panic no longer occurs there (the one with
the oops output), but I still get the other "scsi_free:Bad offset"
panic. For some reason, that particular panic does not produce the
"oops" type output, so there is no traceback to follow. Any idea how I
can get it to supply me with the oops output? I realize this is likely
no longer an XFS problem, but something in the SCSI layer.
In terms of this modification you described, are there any system level
impacts to removing this code? Based on the comments there, it doesn't
seem like there should be. Incidentally, I immediately unmount and ther
remount the filesystem once I'm able to do so (ie: once the FC link is
plugged back in).
>
> What does happen with ext2 - it should be getting I/O errors back from
> the fiber channel driver.
>
I'm still trying to quantify the ext2 behaviour. I have some problems
with a few of my scripts that are designed to handle this scenario. Once
I get those straightened out, I should be able to supply a better
answer.
Sean.
--
Sean C. Kormilo, Software Architect, Nortel Networks
email: skormilo@xxxxxxxxxxxxxxxxxx
|