I see the following error in my system log. It occurs continuously, once or twice a second.

 

reiserfs_read_locked_inode: i/o failure occurred trying to find stat data

 

The error is logged on both md4 and md6. I did a bit of forum research, which lead me to this article:

 

http://lime-technology.com/wiki/index.php?title=Check_Disk_Filesystems

 

So, following the instructions, I stopped the array, started it in maintenance mode and ran a reiserfsck --check on both /dev/md4 and /dev/md6. In both cases the check resulted in the following:

bread: Cannot read the block (244190637): (Invalid argument).

reiserfs_open: Your partition is not big enough to contain the
filesystem of (244190637) blocks as was specified in the found super block.
Failed to open the filesystem.

If the partition table has not been changed, and the partition is
valid  and  it really  contains  a reiserfs  partition,  then the
superblock  is corrupted and you need to run this utility with
--rebuild-sb.

 

The article I linked to above explicitly states not to execute the --rebuild-sb operation without advice from an expert, so I'm here seeking that advice. What should I do? Is there any other information that would be helpful? Just for comparison I ran a --check on /dev/md5 to see what the results were and the --check came back with "No corruptions found". This suggests to me that there is a legitimate problem with both /dev/md4 and md6. If it were only one drive having this problem I would just pull it out, replace it with another drive and let the parity rebuild a proper filesystem over time. However, because I have two questionable drives, I'm not confident in the array's integrity.

 

I recently upgraded to unRAID Server Pro 5.0 final. Previously I had been running one of the RCs. I can't say for sure whether this problem was introduced as a result of the upgrade, or whether I'm just noticing it now and the upgrade is irrelevant. Either way, I haven't noticed any array dataloss yet.

 

Thanks for any help you can provide,

 

-A

A parity rebuild will not fix a corrupt file system. The parity system protects the partition as a whole. A rebuilt disk will have the exact same contents, including the corrupt file system. Attach a syslog. zip it, if needed.

Ah, right. Well, good thing I decided not to take that route then, huh?

 

Here are the syslogs.

 

-A

syslogs.zip

The only option is to try reiserfsck but these errors indicate issues with the SATA card:

Nov 21 11:15:08 Vault kernel: 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
Nov 21 11:15:08 Vault kernel: md: disk0: ATA_OP e3 ioctl error: -22
Nov 21 11:15:08 Vault kernel: 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
Nov 21 11:15:08 Vault kernel: md: disk2: ATA_OP e3 ioctl error: -22
Nov 21 11:15:08 Vault kernel: 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
Nov 21 11:15:08 Vault kernel: md: disk1: ATA_OP e3 ioctl error: -22
Nov 21 11:15:08 Vault kernel: 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
Nov 21 11:15:08 Vault kernel: md: disk4: ATA_OP e3 ioctl error: -22
Nov 21 11:15:08 Vault kernel: 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
Nov 21 11:15:08 Vault kernel: md: disk3: ATA_OP e3 ioctl error: -22
Nov 21 11:15:08 Vault kernel: 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
Nov 21 11:15:08 Vault kernel: md: disk5: ATA_OP e3 ioctl error: -22
Nov 21 11:15:08 Vault kernel: 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
Nov 21 11:15:08 Vault kernel: md: disk6: ATA_OP e3 ioctl error: -22
Nov 21 11:15:08 Vault kernel: 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
Nov 21 11:15:08 Vault kernel: md: disk7: ATA_OP e3 ioctl error: -22
Nov 21 11:15:08 Vault kernel: 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
Nov 21 11:15:08 Vault kernel: md: disk8: ATA_OP e3 ioctl error: -22
Nov 21 11:15:08 Vault kernel: 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
Nov 21 11:15:08 Vault kernel: md: disk9: ATA_OP e3 ioctl error: -22
Nov 21 11:15:08 Vault emhttp: _shcmd: shcmd (167): exit status: 22
Nov 21 11:15:08 Vault kernel: 3w-9xxx: scsi0: ERROR: (0

 

This thread discusses this card: http://lime-technology.com/forum/index.php?topic=2216.0

 

I do not think the card will work in unRAID.

The card has been working in unRAID quite well for a couple years now. Since long before these reiserfs errors began anyway. When I first noticed that opcode error in the log, I contacted LSI and their official position is "This error can be safely ignored".

 

If it were an issue with the card, why would the file systems on drives md4 and md6 be corrupted, but not on drives md1-3,5,7-12?

 

-A

hey check some of my posts on Reiserfs.

 

check all cables are set right,

then you may have rebuild Reiserfs tree if you still have an error.

 

it can take a few hours for each disk but you should get most of it back.

Just a quick update. Over the weekend I ran a

 

reiserfsck --rebuild-sb

reiserfsck --check

reiserfsck --rebuild-tree

 

on both /dev/md4 and /dev/md6. The issue seems to have been corrected. Only one file on each drive was found to be corrupted and removed from the trees. Both files are easily re-downloaded. As to the original cause of the failure, we had a city-wide power outage last week that lasted overnight -- long enough for my UPS to fail. I'm suspecting that as the culprit, but I'll continue to monitor and if the same drives experience problems again I plan to replace them.

 

Anyway, thanks for the advice everyone.

 

-A