One of my drives was missing so I logged in to Tower and this is what I see:

Disk 8 has a red dot, the rest are green. Disk 7 was full and now says "unformatted."

Syslog attached.

Main Page below:

 

Disk status

  Model / Serial No. Temperature Size Free Reads Writes Errors

parity SAMSUNG_HD204UI_S2H7J1BZB14602      22°C  1,953,514,552 - 8,819 1,672 0

disk1  WDC_WD10EACS-00Z_WD-WCASJ1347992 25°C  976,762,552    9,400,360 5,858 6 0

disk2  WDC_WD10EACS-00Z_WD-WCASJ1028698 24°C  976,762,552    833,034,364 5,855 6 0

disk3  SAMSUNG_HD204UI_S2H7J1BZB14593      24°C  1,953,514,552  546,634,572 8,725 6 0

disk4  WDC_WD10EACS-00Z_WD-WCASJ1225075  28°C  976,762,552    11,842,772 5,859 9 0

disk5  Hitachi_HDS72101_GTA000PAGH63DA        36°C  976,762,552    6,202,172 5,857 6 0

disk6  ST31000340AS_9QJ1ZCQ7                        24°C    976,762,552    615,700,752 5,854 6 0

disk7  ST31500341AS_9VS34TT5                        26°C    1,465,138,552  Unformatted 8,765 55 1

disk8  ST31500341AS_9VS1HVL1                        27°C    1,465,138,552  435,792,052 32 0 0

disk9  SAMSUNG_HD204UI_S2H7J1BZB14606    23°C    1,953,514,552  16,690,304 9,445 1,572 0

syslogMarch152014.txt

Do NOT check the "format" box.  Shut down;  check all of your cables -- unplug both the data and power cables for that drive (disk 7) and then reconnect them.  I'd change the SATA cable, just to be sure.

 

Then power it back on and see if you still get the same message.  If so, wait for a Linux guru to provide details on running Reiserfsck -- I'm fairly sure I know the right options to use; but would prefer a Linux-oriented expert walk you through it.

 

 

 

Thanks,

 

I'll try it tomorrow when I get a chance.

 

Joe M.

Do NOT start the array yet, until we have had a chance to think about it more.  There is a very real chance your version of UnRAID will attempt to reformat a drive!

 

Wow!  I'm really afraid you may have waited a little too long to upgrade.  UnRAID v4.5.1 did not have support for the newer 4k-aligned drives, and you have been adding them, so you will have performance issues, once the system is back up and running.  But more importantly, the early versions like v4.5.1 were not safe under some conditions such as yours now, and could very easily result in reformatted drives.  In addition, this version has an earlier kernel that does not appear to be handling a bad IRQ correctly!  Your syslog shows issues with IRQ19, and disabled it twice(!), yet it still assigned it to 4 of your motherboard SATA ports (as well as to some unused USB ports and your SI3132 card, also unused).  I'm really not sure why you aren't showing even more problems!  This may be because of a bad motherboard, or it may be buggy code, which is why I *think* the first step should be to upgrade your flash drive to UnRAID v4.7, and let's see a syslog after that.

 

I have never seen an IRQ disabled twice!  And even more astonishing, I have never seen a kernel go ahead and assign a disabled IRQ again, a third time!  I don't think you should use this version with your hardware.

 

I'm not completely confident in what the next step should be, so am hoping for more of the old-timers to chime in with their ideas.  The reason I think v4.7 should be used is that I'd rather be using fixed and trusted software to do any repairs necessary here, plus it won't attempt to reformat the drive.

 

One thing you should do is change your BIOS settings for the onboard SATA ports.  They are currently set to an IDE compatible mode, and should be changed to AHCI if available or a native SATA mode.  Your 2 JMicron onboard SATA ports are already set to AHCI.

 

As to the Reiser file system damage, I'm not sure it is true or not, because the drive was having problems mounting and there is evidence of an unclean shutdown, so transactions needed to be replayed.  They were successfully replayed on Disk 9, but Disk 8 still had not responded as of the end of this syslog, and Disk 7 shows possible corruption in them.  When these old UnRAID versions would fail to mount a disk, for any reason at all, they would then wrongly assume the drive was unformatted(!), a serious and dangerous error, fixed in later versions.  It's too long ago for me to remember if there was a check box or not.  I don't think there was.  I think it would go ahead and reformat the drive once you started the array!

So what exactly should I do? Upgrade Unraid, restart, capture syslog and post here again?

 

Should I replace disk 8?

 

Also, I did check cables and restart without any change to situation.

 

Thanks,

 

Joe M.

See Check Disk Filesystems  in my sig.

Should I replace disk 8?

Disk 8 appears to be fine, I was wrong above about it not responding, as I missed the line indicating it had finished initializing.  I'm sorry.  I've corrected the Disk 8 statement above.

 

So what exactly should I do? Upgrade Unraid, restart, capture syslog and post here again?

I recommend making a copy of the files on your flash drive, then upgrading it to v4.7, booting it, capturing the syslog, and posting it here.  Let's see if Disk 7 will mount.  If not, then you will need to run a modified form of the instructions on the Check Disk File systems page, replacing /dev/md7 with /dev/sdf1 (or whatever the drive sdx symbol is for Disk 7 then).

Should I replace disk 8?

Disk 8 appears to be fine, I was wrong above about it not responding, as I missed the line indicating it had finished initializing.  I'm sorry.  I've corrected the Disk 8 statement above.

 

So what exactly should I do? Upgrade Unraid, restart, capture syslog and post here again?

I recommend making a copy of the files on your flash drive, then upgrading it to v4.7, booting it, capturing the syslog, and posting it here.  Let's see if Disk 7 will mount.  If not, then you will need to run a modified form of the instructions on the Check Disk File systems page, replacing /dev/md7 with /dev/sdf1 (or whatever the drive sdx symbol is for Disk 7 then).

 

The procedure should be run on /dev/md7 in any case, if it exists. The device, /dev/md7, may exist even if disk7 is not mounted.

Should he mount that disk on a windows box so he can copy the files off it before he goes any further?

I wish I had time right now, but I don't, maybe late tonight.  dgaschk just brought up an important point, which I had forgotten, the virtual version of Disk 7.  The problem is, if we correct the virtual Disk 7, then we have to rebuild the physical Disk 7 and that depends on perfect parity, and we have no assurance that it is.  When was a parity check last run and was it successful?  Also, the original post mentions Disk 8 was red balled, so it too may have issues on the physical Disk 8.  Plus we do NOT have a reliable motherboard and OS yet, with the IRQ issues.  There's a chance that a newer OS, v4.7, will improve that, but no guarantees, so we don't even know yet if we can complete a parity check or sync or drive rebuild.

Not much to add here as I'm tired, but a few more thoughts.  Disk 8 had no transactions replayed, which indicates there were no very recent modifications to the drive, but since we don't know how long it had been red-balled, it is still possible that file modifications have been made to the virtual Disk 8, and not to the physical Disk 8.  If there wasn't a known possibility of modifications to Disk 7 and Disk 8, I would have liked to propose un-assigning the parity disk, then repairing each of the disks, then rebuilding parity.  I'm still hoping someone comes up with a better idea.

 

I still think you should upgrade the flash drive to v4.7 (after backing it up).  Then attach a copy of a new syslog.  I would also like to see other syslogs you may have, to see how common the IRQ issues are.  I'd also like to know when you last ran a parity check, and whether it was successful.

Should he mount that disk on a windows box so he can copy the files off it before he goes any further?

 

This is a good idea. There are several options to image the disks in Windows. Once copies of the disks are made then recovery on image copies can proceed in parallel with recovery of the unRAID server.

I finally have free time to work on this today. First I'll back up the flash drive and upgrade to 4.7. Then I'll post syslog here. Then I'll run check disk file system if 7 doesn't mount. I think disk 8 is messed up but I can lose that disk as the data on it is backed up elsewhere. Disk 7 data is only on this Unraid server.

 

Thanks for the help and I will post back here.

 

Joe M.

I can't find version 4.7 online. Should I upgrade to 5 (or Beta 6)?

Forget about 6 for your situation. It is early beta. I think you have to go to 4.7 in order to upgrade to 5. As it says at the bottom of the download page:

If you require a previous release, please send a request to [email protected].

Thanks.

Email request sent.

 

Joe M.

Good news! Upgraded to 4.7 and disk 7 is back to normal. Disk 8 still shows a red dot and I'm going to replace it. Thanks. What a relief. Is there any need to post my syslog now? Should I upgrade to the latest stable version? I have a second server that has been working fine for years and has an older version of Unraid. Should I upgrade that one even though it's working fine?

 

I'll change title to [sOLVED] after I get a final response.

 

Thanks again,

Joe M.

Good news! Upgraded to 4.7 and disk 7 is back to normal. Disk 8 still shows a red dot and I'm going to replace it. Thanks. What a relief. Is there any need to post my syslog now? Should I upgrade to the latest stable version? I have a second server that has been working fine for years and has an older version of Unraid. Should I upgrade that one even though it's working fine?

 

I'll change title to [sOLVED] after I get a final response.

 

Thanks again,

Joe M.

 

That does *sound* like great news, but I'm not completely convinced without syslogs.  The IRQ issue could have been due to older drivers or kernel stuff from the older release, which you have now replaced with newer, but it could also be due to bugs in your BIOS or the firmware on some addon card or some other motherboard problem.  We need to see your new syslog, and multiple syslogs if possible, just to see how often it popped up in the past, and how often it will in the future.

 

Once we can confirm it looks good, then yes, we recommend upgrading to the current version, at the moment v5.0.5.  Then you can decide if you also want to try a v6 beta.

OK. Here's the syslog (seems like a lot of info about disk 7):

syslog_3_25_14.zip

Uh Oh, Disk 7 folders are empty! The titles are in the folder but nothing is inside.

Also, I upgraded my other server to 4.7 and now one of the disks is showng up as unformatted. Here is the syslog for that server:

tower_syslog_3_25_14.zip

That's most likely because the file system is corrupted.  The files are almost certainly still there, but we still have 2 big problems, fixing the file system on Disk 7 and probably the IRQ issue.

 

Unfortunately, this syslog piece consists entirely of repeats of the following 3 lines (860k worth):

Mar 25 04:40:02 Tower1 kernel: mdcmd (147): spindown 7

Mar 25 04:40:02 Tower1 emhttp: mdcmd: write: No such device or address

Mar 25 04:40:12 Tower1 emhttp: disk_spinning: open: No such file or directory

 

That very likely is because the IRQ was disabled for Disk 7's disk controller, so it cannot be accessed.  That info would be in the initial syslog, which was rotated out.  Try rebooting again, and capturing the syslog as soon as possible.

Also, I upgraded my other server to 4.7 and now one of the disks is showing up as unformatted. Here is the syslog for that server:

 

I'm sorry, I'm going to have to refer you to Tom ([email protected]), and you may wish to point to this post.  The following lines indicate an issue I've never seen:

Mar 25 08:16:55 Tower kernel: REISERFS (device md3): Using r5 hash to sort names

Mar 25 08:16:55 Tower kernel: REISERFS (device md1): Created .reiserfs_priv - reserved for xattr storage.

Mar 25 08:16:55 Tower kernel: REISERFS (device md4): Created .reiserfs_priv - reserved for xattr storage.

Mar 25 08:16:55 Tower logger: mount: Operation not supported

Mar 25 08:16:55 Tower emhttp: _shcmd: shcmd (31): exit status: 32

Mar 25 08:16:55 Tower emhttp: disk3 mount error: 32

Mar 25 08:16:55 Tower emhttp: shcmd (32): rmdir /mnt/disk3

Mar 25 08:16:56 Tower kernel: REISERFS warning (device md3): jdm-20006 create_privroot: xattrs/ACLs enabled and couldn't find/create .reiserfs_priv. Failing mount.

 

Make sure you mention that this failure to mount resulted in the drive appearing unformatted.  While you wait for him, you may try the Check Disk File systems procedure on Disk 3 (md3), but I don't know if that will do anything here.

 

Perhaps someone else has seen the issue above?  He just upgraded to v4.7.

did you have another usb with unraid on it.

I would consider putting V5.05 on it & try in your sever & add another disk as a parity & do a new config.

that way you still have your old parity & 4. usb.

So I rebooted Tower1 and half the disks were missing. I reassigned everything but I can't find the now missing disk 7 and disk 8 says not installed. There is another assignable drive in the device drop down box but the ID doesn't exactly match disk 7 ID (maybe it's disk 8 which was similar to disk 7?). Attached is syslog.

 

Also I rebooted the other server (Tower) and disk 3 remains unformatted. I ran check disk and This is the result:

Replaying journal: Done.

Reiserfs journal '/dev/md3' in blocks [18..8211]: 0 transactions replayed

Checking internal tree.. finished

Comparing bitmaps..finished

Checking Semantic tree:

finished

No corruptions found

There are on the filesystem:

        Leaves 60499

        Internal nodes 369

        Directories 348

        Other files 3559

        Data block pointers 60978696 (0 of them are zero)

        Safe links 0

###########

reiserfsck finished at Wed Mar 26 08:08:10 2014

###########

 

 

Thanks,

 

Joe M

tower1syslog_3_26_14.zip

did you mount that disk in windows to copy the files off as a backup?  can you try that now?  at a minimum if it can read the disk, perhaps you can copy off all of the data.