NASLite Network Attached Storage

Hi:

The console reports the following errors. The SysLog does NOT ... but that may be because the system hung (with the SysLog not getting updated) and I had to do a hard reset to force a reboot. Upon reboot all 3 disks checked clean, and no further errors show on the console ... so I am trying to find out which disk had the problem, and so the question is: What is "device ide0(3,65)" ? (The IDE Master ? Slave ? Possibly the SATA due to IDE mapping ?)

EXT3-fs error (device ide0(3,65)): read_block_bitmap: Cannot read block bitmap - block_group = 961, block_bitmap = 31490048
EXT3-fs error (device ide0(3,65)): ext3_get_inode_loc: unable to read inode block - inode=2, block=21<-- This line appears two additional times with different inodes/block #s.

Then the first & second error lines appear again (but only once each - with identical group/bitmap/inode/block locations) ... and that is all. The system (although responsive to telnet) was hung and would not reboot, needing a hard reset instead.

Thanks in advance for any help.

Georg

Scratch that ! I found my own answer

I had rebooted again with the most likely disk in question set to "--" (instead of RW) so that I could let NASLite do a complete e2fsck, and so I was unable to find the ide0(3,65) device in the SysLog after reboot !

The complete "Checking for badblocks" is still running on this IDE Slave, and hopefully no problems will be found.

Follow-up question: are the errors reported on the console (see above) possibly due to the system being too heavily loaded (which I know it may have been), or is the only possibility a file-system or disk degradation problem ?

Thanks again,
Georg

Not sure but, ide0 is the master drive on the primary IDE controller, so the problem is likely isolated to primary IDE. Most likely it’s a fluke collision due to cable saturation with the slave checks. Regardless, that should not happen and may indicate a bad connector or alike.

I wouldn’t worry about it but will keep an eye on the syslog for related messages once you are back to normal.

Thanks, Tony.

I'm now pretty sure it is the SLAVE on the First IDE channel. "bad blocks" check is at 49 of 73 million. I'll post an update with the entire SysLog for you to look at one more time after all is back to normal (reboot).

And I might try a new cable soon.

Georg

Bad blocks are common and can be found even on new disks. It is indeed a good idea to do a complete check and repair scan of a drive including bad blocks after it's formatted and before sharing it for storage.

The problem goes unnoticed for the most part until a file is written to an area that contains bad blocks. On retrieval of such file one will get an IO error on the client and error messages of that effect in the NASLite syslog. Some drives develop bad blocks soon after initial use, especially in cases where disks run hot. It is a good idea to scan for bad blocks on occasion. It could save your data in extreme cases.

Just some info that may be useful in the future.

Thanks for the advice, Tony.

Just to close the loop, I figured I report on the final status.

The bad-block scan ran to completion without errors. The only message from the e2fsck was "File System Modified". That unfortunately is a little cryptic, but ... oh well.

This Slave disk had some light reading and heavy writing traffic on it when the problem first occurred, including deletion of several dozen files in the 1-4 GB range, just prior to a heavy writing operation. All this activity came from one and the same WinXP system on a GigaBit LAN. I am suspecting (not 100% but a reasonable guestimate) Windows Explorer as the cause of the problem.

Since two days ago no additional console messages.

Yesterday I did a full compare of a 2 day-older mirror to the most current files (about 200GB worth of "stuff") on the affected disk. I used TotalCommander 6.56 (a free download) from Windows Vista for the compare (including content). With the obvious exception of the expected missing files (the one I purposely deleted) all compared fine.

So ... for now ... all is back to normal, and no data loss.

Georg