o0X0o

Thanks. I was cautious of upgrading as I didn't want to introduce more changes, but I've done it now (to 6.8.0) and the result is the same. Looks like I'm off to pickup a new drive so I can have space to move data and convert the file system...

When I run it on the cache drive it seems to work But when I run it on disk 2 I get the same error as when I did it through the console ("reiserfsck --check /dev/md2"):

Just for laughs I tried again, and to my surprise a file moved successfully.. so i tried a second time and got some new errors:

I recently replaced a drive and despite some issues everything seemed like it was ok, until I noticed that the cache drive filled up because the mover was reporting read only errors. Here is an excerpt from the syslog of the last couple of manual triggers of the mover: I put unraid into maintenance mode and tried running "reiserfsck --check /dev/md2" but get this error: bread: Cannot read the block (943196360): (Invalid argument). Failed to open the device '/dev/md2': Unknown code er3k 125 Same message when using --fix. I have run a full SMART test on all drives and they come back fine. I have also enabled disk shares and can see data on the disk in question, so not sure why it would be considered read only. There was a 4kb file on the disk share for one of the files the mover could not move, which I deleted from the cache and then the disk, but it kept reappearing on the disk from somewhere. About an hour after I last tried, it's suddenly gone... What is most strange though, is that the dashboard reports the drive as being bigger than it actually is (3.9Tb instead of 3Tb): If you see my link above, Unraid previously identified that drive's capacity correctly. Not sure if I have a hardware or a software issue.. or gemlins?

Thank you! The array is back up, I have access to my data, and it seems that disk 2 is rebuilding

^bump... I really need to get something off of the array (if it still works...)

Any thoughts or feedback on this one? I think I might have had a power supply problem as well as at least one dying drive. As above, I have put the original Disk 3 back and am thinking of using the new drive that I purchased (and which I had started to use to replace Disk 3), to replace Disk 2 instead. Just seems odd that I'm getting the 'too many wrong disks' warning, and can't start the array, and I am unsure whether to initiate 'new config'... Thanks in advance.

Thanks Squid, really not sure what's going on... some ageing gear in there... Noticed a lot of beeping during startup (which would eventually stop - maybe because drives would spin down), but it didn't seem to match mobo error codes I found online. So I have been mucking around endlessly with cables, splitters and PS, and have seen everything including 0 drives spin up. Right now I think I am closest to a working system, but the one offline drive is not the one I thought... Where I had previously been trying to replace Disk 3, I now cannot get Disk 2 going... however other drives connected to the same power/data cables are fine, so I think that's the worst drive. Disk 3 is what I had previously thought I needed to replace, and the rebuild process ran for a bit but never completed. I put the original Disk 3 back and assigned the new drive to Disk 2, but now I get "Too many wrong and/or missing disks!". Can I just run 'new config' or do I risk data loss?

Hi all, Summer is upon us down under, and I've recently started receiving temperature alerts for some of my drives during the day. Today one drive was appearing as offline, so I threw in a new one to begin the replacement process, but the rebuild process is reporting heaps of errors: I haven't really shown my unraid server much love in a while, and I'm not exactly up to speed anymore. Is this something I should be concerned about? Appreciate any feedback on what's going on, and if I need to be taking any particular action. Thanks. tower-diagnostics-20191116-1306.zip

Thankyou, I'll do that ASAP. I also want to remove the PATA drive (don't want to be caught in a similar position in the future should it fail). I will then pull one of the 1Tb SATA drives and replace with the new 3Tb drive. I did a search and found 2 very different approaches: [*]This one discusses removing from shares, renaming folders, and manually moving data: http://lime-technology.com/wiki/index.php/Shrink_array [*]This one moves the data to the cache drive, and creates a new config with the (old data) drive removed from the array: http://lime-technology.com/wiki/index.php/FAQ_remove_drive Both also use MC instead of windows explorer to move the data - is this just for performance (so that the data transfer is local to the unraid server, and not across the network)? The second option seems the simplest. Is there a preferred (or even alternative) method?

Thankyou - I have swapped the drives back, initiated 'new config' and put the drives back in the same order. Parity rebuild is running, and my data seems to be back. While I am here, is it worth upgrading unraid?

And now the web interface (and unmenu) is not responding. Should I follow this guide and remove the new drive?: http://lime-technology.com/wiki/index.php/UnRAID_Manual_5#Remove_one_or_more_data_disks Then re-add the old drive and create a new config?

I had 9 data disks - one of which (the smallest) was a PATA drive. My system has been stable for a looong time, but I recently ran out of space so procured a 3Tb SATA as a replacement. Before I started the process there were no errors and parity was good. The only free slots were on a PCI-x controller. The first port I connected it to made boot take ages, and a number of IO errors on the screen. Shut it down and moved it to the other port and all looked good, so proceeded with the standard upgrade process. Web interface and shares were unresponsive for a period, however they came back and the process seemed to progress well. A refresh this morning shows it completed, however 2x drives (one of which is on the same controller) are now reporting massive error counts. Shares are up, however some won't open and those that do have almost no data in them. UPDATE: At the console I see a screen full of REISERFS errors for "(device md1)" I'm guessing that the problem is the PCI-x card (possibly in combination with mobo IRQ?) and that best course may be to rollback. I am nervous because parity seems to have been written to - is it as simple as pulling the new drive and replacing the old? I am still using 5.0 RC12a. Screenshot attached. Syslog is at 78Mb and still generating so I haven't attached yet. Will do so when it completes if anyone thinks it might be useful.

Came across another unraid user with problems: http://lime-technology.com/forum/index.php?topic=24646.0 And I just read some comments elsewhere that users have needed to disable some on-board Marvell based SATA controllers to get this (PCI-x Marvell based SATA controller) to work... which typically means losing 2x SATA ports. I suspect this is the case for the above link (an old post I didn't want to dig up by replying to).

Mine says V1.0 and uses a Marvell 88SE9230. It is also screen printed with both "Rocket 640L" and "RocketRAID 640L" (see pic) which is interesting... the box just says Rocket. The difference seems to be support for RAID 0/1 vs 0/1/5/10/JBOD, and I have seen suggestions elsewhere that the RocketRAID 640L actually uses a 88SE9235. If true, then I do indeed have a Rocket 640L. Highpoint website suggests that there is now a "2nd Gen" version of the card (however is only ever referred to as "RocketRAID"), and which is again reported to use a Marvell 88SE9235. I note in some of the links in your sig that you are/were using a RR620 (not a 640) with a patched kernel and script to enable support for Marvell 88SE9128, however my 640L uses a Marvell 88SE9230 Would be good to know what card, version and chip you have, as well as how many drives/which ports you are using!