I've only recently come to the conclusion that one of my SATA controllers (a Highpoint Rocket 640l) is likely incompatible with unraid, and drops disks when under load - such as when doing a parity check. Normally a reboot makes all the drives come back, but for some reason unraid red-balled one of the drives when this last happened. I followed the process below (from the FAQ) to re-enable the drive:

 

1. Stop the array, go to the Devices page and un-assign the disk

2. Start the array.

3. Stop the array, go to the Devices page and re-assign the disk

4. Go back to the Main page - the system should detect a "new" drive for the one disabled, click the Start button to start the rebuild (parity-reconstruct) of the disk (you may have to click the little check box under the Start button that says "I'm sure I want to do this") (post with screen shots)

5. Drive will now be rebuilt, takes a while; the array can be used at the same time, but we recommend waiting until the rebuild is complete. The procedure of un-assigning the drive, starting the array without it, and then re-assigning it allows a drive to be used as its own replacement.

 

Oddly, throughout the rebuild process the drive continued to appear as unformatted and has remained so even after the rebuild was complete and a subsequent reboot. The drive is green but seemingly has not mounted. Drive passes all SMART tests.

 

Server is running 15a and the only plugin is unmenu (with some basic packages such as hourly email alert and monthly parity check). I haven't posted a syslog as I would need to strip it of some info (like email settings), and wasn't sure if there would be anything useful in it anyway since the drive appears in unraid fine - other than being unformatted...

 

I will take steps to move away from the Highpoint Rocket 640l asap, but would appreciate help getting the drive (and its contents!) restored.

 

Please help!

 

anyone...?

See check disk filesystems in my sig. Are you running Simplefeatures with debug on?

Thanks for the reply. I followed that instruction and the drive no longer appears in unraid as unformatted, however if I browse the disk share I can only see some folders - no actual files, and I'm pretty sure it's not the full directory structure either...

 

I had to run 'reiserfsck --rebuild-tree' and saw file names flash up in the telnet session, so wondering where the data is..! There is no lost+found visible to me via the disk share.

See here: http://lime-technology.com/forum/index.php?topic=1483.msg9973#msg9973

Sorry, are you suggesting that I now use "reiserfsck /dev/md4" followed by "reiserfsck --rebuild-sb", or that I should use SpinRite?

 

And apologies - I didn't answer your question re: SimpleFeatures: No, this particular unraid server is only running unmenu.

I try this to recover lost file:

 

I then needed to get reiserfsck to search the entire drive to try and rebuild the directory structure.  I ran the program 
      “reiserfsck –scan-whole-partition –rebuild-tree /dev/md1”.  (UPDATE 8/8/11: If you ever run on on an OS level device rather than an unRAID device, make sure to use the first partition - ie., “reiserfsck /dev/sdc1", and not the disk level device.)

Thankyou for the clarification and sorry for the delay. I haven't run it yet, because the SATA controller red-balled another disk and I had to rebuild that one as well (which worked thankfully!). I have now eliminated the controller by moving to another mobo (which then gave me HPA problems that I also had to fix) but the system is now (fingers crossed..) stable.

 

I was about to run the command in your last post, but noticed that there is now a lost+found folder user share (and corresponding folder visible via the disk share) which I had not noticed before. I don't seem to have permissions to it despite it being 'public', so went to explore the disk share and found that a large number of directories and files are now back... there were a couple of image files that seem to be corrupt and a lot of empty folders, but every other file I tested was good.

 

So, I guess is my question is now wether I should still run the command in your last post, or should I try to gain access to the lost+found user share (by running utils\new permissions) and manually move the files to the appropriate disk (or user?) share?

 

Run New Permissions. Running New Permissions should always be safe unless you've customized the permissions of an add-on.

I ran 'new permissions' and two issues:

[*]can now access the lost+found folder, but it's empty...

[*]I got a whole heap of  REISERFS errors for another disk (the second drive to red-ball, and which I thought I had rebuilt without issue)

 

excerpt from syslog:

Jul 6 19:47:20 supernas kernel: REISERFS warning: reiserfs-5090 is_tree_node: node level 2054 does not match to the expected one 2

Jul 6 19:47:20 supernas kernel: REISERFS error (device md5): vs-5150 search_by_key: invalid format found in block 345997314. Fsck?

Jul 6 19:47:20 supernas kernel: REISERFS error (device md5): vs-13070 reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [4 730 0x0 SD]

Jul 6 19:47:20 supernas kernel: REISERFS warning: reiserfs-5090 is_tree_node: node level 29140 does not match to the expected one 1

Jul 6 19:47:20 supernas kernel: REISERFS error (device md5): vs-5150 search_by_key: invalid format found in block 346201248. Fsck?

Jul 6 19:47:20 supernas kernel: REISERFS error (device md5): vs-13070 reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [4 33 0x0 SD]

 

Should I run "reiserfsck –scan-whole-partition –rebuild-tree /dev/md??" on both of these drives?

 

Run with --check first.

Thanks. I ran "--check" on md5 and it suggested I run "--rebuild-tree" so kicked that off. Has been running for hours now even though that disk had no files visible via the disk share. Unsure if it's parity info that's being processed, or lost files...

 

The count in the telnet session continues to tick over, however tower/main reports no space used on the drive and unmenu reports "-91579.00K" - weird in a few ways... but why take so long to remap a (supposedly) empty drive...

 

The same drive passes a SMART test.

 

EDIT: has been stuck for hours on "unknown item type found" a bunch of gibberish then "<15>] - deleted"

EDIT2: vpf# has incremented in the last few minutes, and now ends with "wrong offset is deleted" so I will let it run overnight before I update again.

returned to console. last line in syslog is:

 

reiserfsck[6598]: segfault at 30203ca ip 0804a998 sp bfd4ee90 error 4 in reiserfsck[8048000+4a000]

Run memtest overnight.

Have now completed 10 passes and no errors 

Post a SMART report.

FYI: 14hrs and 18 passes of memtest with no errors

 

SMART report attached.

 

P.S. Upon reboot it seems that a parity check has been initiated. Should I kill this in case it leads to data loss?

md5.txt

Attach a syslog.

syslog attached - thanks again

syslog.txt

The syslog indicates all drives are operating correctly. Attach a sreenshot of the GUI

unmenu screenshot attached

 

Cannot seem to run reiserfsck at the moment due to the parity check running.

The syslog and the screenshot indicate that the server is working correctly. What is the issue?

There are two disks with issues:

 

[*]Disk 4 - red-balled, was rebuilt but then appeared as unformatted. Used reiserfsck to rebuild tree but not all files restored and no lost+found. You suggested I run "reiserfsck –scan-whole-partition –rebuild-tree /dev/md4" but before I did Disk 5 re-balled as well so I dealt with that first. Once that was back lost+found appeared (IT-fairies?) but I didn't have permissions... once I gained access found it to be empty. Parity check then decided to run and ever since, all attempts to use reiserfsck result in "Partition /dev/mdX is mounted with write permissions, cannot check it"

[*]Disk 5 - also red-balled but this time supposedly rebuilt without issue. Noticed reiserfs errors in syslog so ran"--check" on md5 and it suggested I run "--rebuild-tree" which ran for hours even though that disk had no files visible via the disk share. Unsure if it' was parity info that was being processed, or lost files... after a significant amount of time it appeared to be stuck on "unknown item type found" a bunch of gibberish then "<15>] - deleted". vpf# then incremented to end with "wrong offset is deleted". Parity check decided to run and now all attempts to use reiserfsck result in "Partition /dev/mdX is mounted with write permissions, cannot check it". Console reports that this drive has used 1Tb, however I can only see 3Gb of data on it (that I could not see before). There is also now a lost+found folder on the disk, but again I don't have permissions to this and properties suggest it is 0kb

 

Parity check started automatically on last few reboots, and even if I stop the check and stop/start the array I still get "mounted with write permissions, cannot check". I presume starting in maintenance mode won't help. This particular unraid server runs 15a, so I think it has the safe-mode boot option if that would help?

 

Not really sure where to go from here...

See Check Disk Filesystems in my sig.

Parity check started automatically on last few reboots, and even if I stop the check and stop/start the array I still get "mounted with write permissions, cannot check". I presume starting in maintenance mode won't help. This particular unraid server runs 15a, so I think it has the safe-mode boot option if that would help (and allow me to use reiserfsck as per the link in your sig)?

 

I have googled the error ("mounted with write permissions, cannot check it"), and the only links are to unraid forum pages where others have experienced, but have not stated what resolved (or seem to have rebuilt the drive).

 

It is suggested a couple of times to unmount the disk (using "unmount /mnt/disk5"), but:

• this also doesn't work ("-bash: unmount: command not found)
  
• Doesn't the drive need to be mounted to be able to check it?