Eli Morris put forth on 7/11/2010 8:10 PM:
>Hi guys,
>
>Here are some of the log files from my XFS problem. Yes, I think this all
>started with a hardware failure of some sort. My storage is RAID 6, a an
>Astra SecureStor ES.
>
>
> [root@nimbus log]# more messages.1 | grep I/O
>Jul 2 17:02:30 nimbus kernel: sd 6:0:0:0: rejecting I/O to offline device
>Jul 2 17:02:30 nimbus kernel: sd 6:0:0:0: rejecting I/O to offline device
>Jul 2 17:02:30 nimbus kernel: sr 5:0:0:0: rejecting I/O to offline device
<snip>
What does the web gui log on the Astra ES tell you?
If the Astra supports syslogging (I assume it does as it is billed as
"enterprise class") you should configure that to facilitate consistent error
information gathering--i.e. grep everything from one terminal session.
--
Stan
Hi,
After I got into work on Tues, I looked at the log files from the web interface
for the Astra RAID controller. I also contacted support and sent them a system
report, which contains the logs as well as information about the system.
Neither he, nor I, saw any problems in the log files. The support person said
he could not find any problems with the units. The only thing he mentioned was
that I should turn off the SMART daemon, because it does not work with RAID
units. I'll note also that since the day when the I/O errors occurred, I have
not seen any additional errors from the units, although that may be because we
are not reading or writing to them for obvious reasons.
If it turns out we can not recover the lost amount of data, I still would need
to get the remaining filesystem stable, so we can restore what we can from
backup and get going again. And I'm really wondering why if I grow the
filesystem back to the size of the LVM logical volume, when I run xfs_repair,
it shrinks back down again. For all I know, that always happens, when one runs
xfs_repair on a just expanded file system. I'll check into the syslogging
capability of the Astra, but as of now, I have to look at its separate log
files from the web gui.
thanks,
Eli
|