This is a problem I have that isn't confined to UnRaid 6 but I cannot find a general errors area to put it in. Mods, please move as you see fit.

 

I have two UnRaid flash drives which I alternate when upgrading, thus keeping a working copy at all times.  At least that is the intention.  Disk 1 runs v5.0 beta14 and I just upgraded disk 2 to v5.0.5 because access to the web GUI had slowed to a crawl and sometimes dropped the connection.  This problem has not been solved by upgrading (via a reformatted flash drive) to 5.0.5 and I have discovered, by connecting a monitor to my UnRaid server, that I have a series of REISERF errors.  The error appears to be related to some documents in a folder on drive 4.  I don't know whether deleting and reinstalling those documents would cure the problem, or whether the error is more serious.  Last night I did a complete drive check on drive 4 using the GRC spinright program and came up with no significant errors (7 write errors on a 2Tb drive).

 

I attach the first lines of the syslog for both flash disks (separate post for disk2 due file size limitations).

 

Please, could somebody guide me here.  This is WAY outside my knowledge and comfort boundary.

 

Many many thanks

 

 

 

Syslog_03-10-14_Flash_drv1.txt

syslog disk2

 

Syslog_03-10-14_Flash_drv2.txt

Looks like you need to run reiserfsck on disk 4

 

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

That's kind of you to suggest, Squid.

 

I have picked up from some hero members that running an fsck check is not for the faint hearted and not until after seeking advice on this forum.  It would be nice if some of those experts could now advise me how to proceed.  For instance, where is the corrupted table for the disk stored?  If it is stored on the drive itself, could one not just replace the disk and rebuild it from the parity drive?

 

I'm not averse to running an fsck check but I am familiar with non reversible disasters and I try to avoid them where possible.

 

What are my options, I wonder?

That's kind of you to suggest, Squid.

 

I have picked up from some hero members that running an fsck check is not for the faint hearted and not until after seeking advice on this forum.  It would be nice if some of those experts could now advise me how to proceed.  For instance, where is the corrupted table for the disk stored?  If it is stored on the drive itself, could one not just replace the disk and rebuild it from the parity drive?

 

I'm not averse to running an fsck check but I am familiar with non reversible disasters and I try to avoid them where possible.

 

What are my options, I wonder?

You should stop the array and then restart it maintenance mode.    Use the instructions from the link to run reiserfsck with the --check option.  This is safe to run the check option  - it is when reiserfsck offers suggested repair options that you need to check back as those are the actions that can cause damage if used incorrectly.

Brilliant, thank you

 

I shall do that and report back in a couple of days. (I am currently away from home).

I've run the fsck check a couple of times.  The first time, though, the telnet the connection was closed by the server and the results never displayed, and the second time via the terminal.  I attach the final screenshot.  Does that give enough information?  It does refer to two items which can only be fixed when running with --rebuild-tree.

 

It also refers to putting the fsck log into 'stdout'.  Where would I find that, I wonder?  Alternatively, how do I prevent the server from closing the telnet connection?  Probably simple questions but that is what I am 

 

Thanks guys

What was the exact command that you typed?

 

Hi dgaschk

 

reiserfsck --check /dev/md4

 

.

Run with rebuild-tree