jgc

I was running a parity sync and had an issue with one of my off-line drives which caused the web gui to stop responding. I found this post helpful in confirming that the parity check was still running. Thank you all. I anticipated not being able to access the gui for the duration of the sync, so I took the details from this thread and produced a bash script that replicates the information provided in the web gui: #!/bin/bash status=$(mdcmd status | sed -n 's/mdState=//p') size=$(mdcmd status | sed -n 's/mdResync=//p') pos=$(mdcmd status | sed -n 's/mdResyncPos=//p') dt=$(mdcmd status | sed -n 's/mdResyncDt=//p') db=$(mdcmd status | sed -n 's/mdResyncDb=//p') gbsize=$(awk "BEGIN{ printf \"%.0f\",$size * 1024 / 1000^3}") gbpos=$(awk "BEGIN{ printf \"%.0f\",$pos * 1024 / 1000^3}") progress=$(awk "BEGIN{ printf \"%.1f\",($pos / $size) * 100}") speed=$(awk "BEGIN{ printf \"%.1f\",($db/$dt) * 1024 / 1000^2}") finish=$(awk "BEGIN{ m=(($dt*(($size-$pos)/($db/100+1)))/100)/60 print int(m/60) \"h \" int(m%60) \"m\" }") echo "Status: $status" echo "Progress: $gbpos GB of $gbsize GB (${progress}%)" echo "Speed: $speed MB/sec" echo "Finish: $finish" You can create this from the console using nano or vi. I saved as /boot/syncstatus, and made executable with `chmod +x /boot/syncstatus` If you run this once it will output the current status: Status: STARTED Progress: 1101 GB of 4001 GB (27.5%) Speed: 138.3 MB/sec Finish: 5h 49m If you want the information to continually update then you can use the `watch` command: watch /boot/syncstatus This will print the sync information and refresh the information every 2 seconds. You can change the polling period using the -n option (`watch -n 10 /boot/syncstatus` for every 10 seconds).

Hate to state the obvious, but it says "Set when adding new share only.", so I would assume no. Are you using btrfs? If not, then it shouldn't matter.

That makes me feel much better, thanks Frank!

Thanks for your prompt reply Frank1940, I've added my setup details to my profile. I've also got an IO Crest 4 Port SATA III PCI-e 2.0 card, and an Nvidia Quadro 4000. I originally used the 5 motherboard SATA ports for the drives (the IO Crest card was for expansion). When I started getting the read errors I wanted to isolate the problem, but I didn't have any spare cables so I shut everything down, pulled the SATA cable from the back of the bad drive and from the back of a behaving drive and swapped them around. My thinking was that if it was the cable or the motherboard port then the bad drive would start behaving, and the other drive would start producing errors. If it was a bad drive then it would carry on erroring, which it did. I'm not using locking SATA cables, so I did also go through all the drives and ensure the cables were seated well, and the power cables were all seated OK. The motherboard is set to use AHCI mode. Thanks for the feedback johnnie.black. I agree these don't look good. Is it at all possible they could be caused by bad mobo/ports/cable? Annoyingly I'm out of the Amazon return period, so I think I'm going to have to go back to WD for the RMA. Any advice before I do?

I am new to unRAID, and have built an array (v6) with a bunch of mostly new drives. One of them seems to be having problems (a 4TB WD Red, serial ending in VAX). Background: I was in a hurry to try unRAID out so I only did one pass of pre-clear on each drive, and this ran with no problems for all drives. Everything was good until I tried to run a time-machine backup. I setup a time machine AFP share using only one drive (advice I'd seen on the forums), and this was on the 4TB WD Red. During the backup I got a lot of disk errors (I think they were read errors), and the backup failed. I left it at that (don't have much spare time to spend on this, and the TM backup wasn't urgent). A couple of days ago I swapped the SATA cables with another drive to determine whether it was a bad cable or port (I don't have spare cables, so swapping seemed like a logical approach). That day I got a write error message for the drive and it was kicked from the array. I sat down to work out what the problem was with the drive - to determine whether to RMA it. I ran a short and long smart test, and each time they come back good. No bad / reallocated sectors, most things look ok to my uneducated eye. So, based on other forum posts I decided to try and rebuild the drive (I figured it would either work, or prove the drive was bad). I went through the process of de-assigning and re-assinging the drive, and started the re-build. It ran for a few hours then hit a whole load of write errors. This is where I am now. I downloaded the diagnostics, and took a look through them. I want to RMA the drive, but the thing that's bugging me is that the SMART reports only list read errors, and doesn't mention any write errors. Could it be that the drive is good and the write errors are from a bad cable / SATA port. I just don't know how to tell. I don't want to send the drive back to Amazon and have them deem it's OK. Can anyone offer advice on what to do to prove or disprove this is a bad drive? Are there any signs I'm missing in the SMART reports? tower-diagnostics-20160507-0135.zip