I am using 4.7

I have attached a syslog. It seems to transfer very slow for some reason. My other 2 towers are fine.

Anyone have any ideas why?

Thanks

syslog.txt

Post a SMART report for sdk.

How do I do that? Sorry but I do not know

http://lime-technology.com/wiki/index.php?title=Troubleshooting#Obtaining_a_SMART_report

I will run it on /dev/sdk as soon as I get home tonight and post the results

 

Here is the smart report for sdk

 

smart.txt

RMA time. That drive is toast.

I just replaced the drive and now it says Upgrade disk. I started the array and the drive has an orange dot and it says it is starting. It has been starting for 15 minutes or so.

Is this normal?

 

This normal? Been running like this for a while

 

Hard to read the picture - resolution is too low.

 

However, did you preclear the drive before trying to add it to the array?  If not, then unRaid will take a while (hours) to initialise the drive before it adds it into the array.  So this *could* be normal, depending on what you did.

ah yes... I did not preclear it so that explains it.

Oh well. I will wait

 

Refresh the browser to get progress updates.

The web page does not seem to be loading for me so I cannot tell if the upgrade of the disk is done or not

Is there a process I can check in putty?

What should I do?

 

The web page does not seem to be loading for me so I cannot tell if the upgrade of the disk is done or not

Is there a process I can check in putty?

What should I do?

tail -f /var/log/syslog

In most releases, the progress is written to the system log

depending on the size of the disk, the writing of zeros to it can take many hours, during which the array will not be accessible.

 

Most disks write at a rate of between 65 and 100MB/s.  At 100MB/s it will take 10 seconds to zero a Gigabyte.

That is 6 GB per minute, and (assuming) with a 2TB drive you have 2000GB to zero. 2000/6 = 333.3 minutes, or 5.55 hours...

 

Most drives cannot sustain writing 100MB/s on inner cylinders, so expect it to take 6 hours or more.

This is what I see

 

Mar  1 12:18:36 Tower login[12498]: ROOT LOGIN  on `pts/0' from `192.168.1.50'

Mar  1 12:19:29 Tower kernel: ata14.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0

Mar  1 12:19:29 Tower kernel: ata14.00: BMDMA2 stat 0xd0009

Mar  1 12:19:29 Tower kernel: ata14.00: failed command: READ DMA EXT

Mar  1 12:19:29 Tower kernel: ata14.00: cmd 25/00:00:9f:4f:02/00:04:ae:00:00/e0 tag 0 dma 524288 in

Mar  1 12:19:29 Tower kernel:          res 51/40:7f:15:52:02/00:01:ae:00:00/f0 Emask 0x9 (media error)

Mar  1 12:19:29 Tower kernel: ata14.00: status: { DRDY ERR }

Mar  1 12:19:29 Tower kernel: ata14.00: error: { UNC }

Mar  1 12:19:35 Tower kernel: ata14.00: configured for UDMA/100

Mar  1 12:19:35 Tower kernel: ata14: EH complete

Mar  1 12:19:45 Tower kernel: ata14.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0

Mar  1 12:19:45 Tower kernel: ata14.00: BMDMA2 stat 0xd0009

Mar  1 12:19:45 Tower kernel: ata14.00: failed command: READ DMA EXT

Mar  1 12:19:45 Tower kernel: ata14.00: cmd 25/00:00:9f:4f:02/00:04:ae:00:00/e0 tag 0 dma 524288 in

Mar  1 12:19:45 Tower kernel:          res 51/40:7f:1d:52:02/00:01:ae:00:00/f0 Emask 0x9 (media error)

Mar  1 12:19:45 Tower kernel: ata14.00: status: { DRDY ERR }

Mar  1 12:19:45 Tower kernel: ata14.00: error: { UNC }

Mar  1 12:19:51 Tower kernel: ata14.00: configured for UDMA/100

Mar  1 12:19:51 Tower kernel: ata14: EH complete

 

The web page does not seem to be loading for me so I cannot tell if the upgrade of the disk is done or not

Is there a process I can check in putty?

What should I do?

tail -f /var/log/syslog

In most releases, the progress is written to the system log

depending on the size of the disk, the writing of zeros to it can take many hours, during which the array will not be accessible.

I thought upgrading an existing disk just rebuilt the data from parity + rest of drives, expanded the partition if there was extra space, and zeroed the newly allocated portion. So it zeros the entire space first? I've always upgraded drives with precleared spares, so I don't know from experience.

This is what I see

 

Mar  1 12:19:29 Tower kernel: ata14.00: failed command: READ DMA EXT

Mar  1 12:19:29 Tower kernel: ata14.00: cmd 25/00:00:9f:4f:02/00:04:ae:00:00/e0 tag 0 dma 524288 in

Mar  1 12:19:29 Tower kernel:          res 51/40:7f:15:52:02/00:01:ae:00:00/f0 Emask 0x9 (media error)

 

Did you reconfigure anything physically when you replaced the bad drive? That message is telling me that you have another failed drive, but from that snippet I can't tell which one. If my sleuthing skills are good, it should be the drive that's plugged into port 4 of a controller. I think it might be a PCI 4 port card, I'm not good enough at reading syslogs to be confident about it though. In any case, I hope you have the contents of this server backed up elsewhere, because it's looking like a second drive failed while you were in the process of trying to rebuild the first failed drive. Are you sure you removed the correct drive to replace?

I did nto change anything.

Just took out the bad drive and put in the new one for disk5

Then it has been rebuilding for the last couple of days.

 

A parity check is scheduled to run on the first of the month. Do you think it is causing an issue?

 

BTW, the rebuild is very slow... running at 40 KB/sec and sitting at 99.8%

This is what I see

 

Mar  1 12:18:36 Tower login[12498]: ROOT LOGIN  on `pts/0' from `192.168.1.50'

Mar  1 12:19:29 Tower kernel: ata14.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0

Mar  1 12:19:29 Tower kernel: ata14.00: BMDMA2 stat 0xd0009

Mar  1 12:19:29 Tower kernel: ata14.00: failed command: READ DMA EXT

Mar  1 12:19:29 Tower kernel: ata14.00: cmd 25/00:00:9f:4f:02/00:04:ae:00:00/e0 tag 0 dma 524288 in

Mar  1 12:19:29 Tower kernel:          res 51/40:7f:15:52:02/00:01:ae:00:00/f0 Emask 0x9 (media error)

Mar  1 12:19:29 Tower kernel: ata14.00: status: { DRDY ERR }

Mar  1 12:19:29 Tower kernel: ata14.00: error: { UNC }

Mar  1 12:19:35 Tower kernel: ata14.00: configured for UDMA/100

Mar  1 12:19:35 Tower kernel: ata14: EH complete

Mar  1 12:19:45 Tower kernel: ata14.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0

Mar  1 12:19:45 Tower kernel: ata14.00: BMDMA2 stat 0xd0009

Mar  1 12:19:45 Tower kernel: ata14.00: failed command: READ DMA EXT

Mar  1 12:19:45 Tower kernel: ata14.00: cmd 25/00:00:9f:4f:02/00:04:ae:00:00/e0 tag 0 dma 524288 in

Mar  1 12:19:45 Tower kernel:          res 51/40:7f:1d:52:02/00:01:ae:00:00/f0 Emask 0x9 (media error)

Mar  1 12:19:45 Tower kernel: ata14.00: status: { DRDY ERR }

Mar  1 12:19:45 Tower kernel: ata14.00: error: { UNC }

Mar  1 12:19:51 Tower kernel: ata14.00: configured for UDMA/100

Mar  1 12:19:51 Tower kernel: ata14: EH complete

UNC + "media error" = uncorrectable read error.  (unreadable sector... marked for possible re-allocation)

Joe... What does that mean?

The drive that is rebuilding is disk5

 

The rebuild will have errors and may totally fail. All of the other disks must be read successfully to perform a rebuild. Post a new syslog.

OK so the rebuild finished but when I restarted the unraid system it said it was doing the rebuild again.

Here is the current syslog. The rebuild gets to 98.9% and then seems to really slow down.

I ran a smart report on all drives and they reported as fine.

I have no idea what is going on. please help me get my tower back to normal.

 

How can I tell unraid to just skip the rebuild process and leave the drive empty. There were only a few files on it anyway.

 

Thanks

syslog.txt

OK so the rebuild finished but when I restarted the unraid system it said it was doing the rebuild again.

Here is the current syslog. The rebuild gets to 98.9% and then seems to really slow down.

I ran a smart report on all drives and they reported as fine.

I have no idea what is going on. please help me get my tower back to normal.

 

How can I tell unraid to just skip the rebuild process and leave the drive empty. There were only a few files on it anyway.

 

Thanks

Simple.

 

Stop the array

Un-assign the disk

Set a new disk configuration  (depending on unRAID version, either use the "initconfig" commanf or use the New Config button on the utilites page.)

Start the array without the disk in the array.  Parity is instantly invalidated when you set a new disk configuration.  It will be calculated again when you next start the array.

It is rebuilding parity now. Thanks Joe.

I hope this fixes everything

 

Joe,

The parity seems to build find up until near the last few %, then it really slows down to a crawl

Here is a screenshot