Upgraded to 6b10a a few days ago from 6B6, and have had this problem repeat itself:

 

1. Fresh boot, run parity check, get 150MB/sec.  All is good.

2. Parity check finishes at full speed.

3. Wait 24 hours, with no unRAID activity other than the parity check and copying a few files.

4.  UI becomes sluggish (3 seconds to go between tabs) and I/O goes to crap.

 

Nothing is running in the background.  CPU is idle, so no problems there.  mpstat indicates time is going into waiting on disk.

 

Tried syncing discs, making sure all are spun up, flushing caches, etc., but no change.

 

Reboot, makes everything OK again... until the next day.

 

I'm not using plugins or docker (booting plain unRAID w/o xen)

 

Nothing is running in the background.  CPU is idle, so no problems there.  mpstat indicates time is going into waiting on disk.

Can you determine if that mpstat indication is normal or unusual?  If you check right after booting with nothing running in background and CPU's idling, what does mpstat indicate?

 

3. Wait 24 hours, with no unRAID activity other than the parity check and copying a few files.

4.  UI becomes sluggish (3 seconds to go between tabs) and I/O goes to crap.

 

Can you determine a little more specifically when this degraded state begins?  Does it seem fine immediately after the parity check, an hour later, 10 hours later, after a high I/O event such as the mover?  And is it a slow slide down or rather sudden?

Try changing the sata cables?

 

 

Parity check finished Fri 17 Oct 2014 06:23:40 PM EDT (today).  Average speed: 126.1 MB/sec.

 

Currently it is behaving.   But those were the same results I got yesterday, and when I go up this morning, it was back to crap.

 

How many clients are you checking with. I had a similar problem but it ended up being the windows drivers throttleing the nic speed after pc sleeping. I reset all drivers in windows to stop doing that and went back to normal.

 

Just a thought

I believe I've found the culprit.

 

The problem varies from appearing in a day or so, to sometimes not for several days.  When the problem occurs, there are a lot of zombie smartctl and hdparm processes hanging around.  If I kill them, server responds normally for a few seconds, and then a new batch of smartctl processes are launched and the system goes back to molasses.

 

Upgraded to B12 and the same problem remains.

 

This is likely related to the fact I use an Areca controller, so smartctl requires special switches and hdparm won't work at all.

 

One solution is to allow the user to customize smartctl/hdparm commands in the UI per disk for getting temps, spin up/down, etc.

 

 

 

I believe I've found the culprit.

 

The problem varies from appearing in a day or so, to sometimes not for several days.  When the problem occurs, there are a lot of zombie smartctl and hdparm processes hanging around.  If I kill them, server responds normally for a few seconds, and then a new batch of smartctl processes are launched and the system goes back to molasses.

 

Upgraded to B12 and the same problem remains.

 

This is likely related to the fact I use an Areca controller, so smartctl requires special switches and hdparm won't work at all.

 

One solution is to allow the user to customize smartctl/hdparm commands in the UI per disk for getting temps, spin up/down, etc.

 

 

In the short term, you could create wrappers.

I.E. move the executable to hdparm.exe create a script called hdparm that inspects the parameters and adjusts accordingly.

 

 

I did this with smartctl so I could capture the smart output that was being piped back to emhttp.

kludge but it works.

[quote author=WeeboTech link=topic=35830.msg340955#msg340955

In the short term, you could create wrappers.

 

That's actually what I did but it's more trouble than its worth to either 1) make it foolproof and handle changing device assignments, or 2) redo it every time devices change.

 

 

You can walk the directory of /dev/disk/by-id/ do readlinks to find the matching device.

Once you know the matching device, Now you know what you are working on and can adjust accordingly.

 

There's also ways to grep the device name from /proc/mdcmd.

I have a function to load it into a bash array so I can do other things like display relevant mdstatus data into the syslog, /etc/motd, /etc/issue.net

 

I know you said it's more trouble then it's worth, but if you are interested in not reinventing at least that small wheel, you are welcome to it.

I have an Areca controller and never noticed this. I am still on beta 9. Is it new in beta 10?

I have an Areca controller and never noticed this. I am still on beta 9. Is it new in beta 10?

 

Which controller?  Are you using RAID0 spinners to present a single volume to unRAID?

Yes, ARC-1200.

I'm running an ARC-1880IX-16 w/ 4GB cache

Forgive the short reply, but let me know if this issue still persists for folks and what recommended solutions any of you guys have.  I saw a few recommendations in this thread to offer UI controls on a per disk basis for smartctl, but I think that's probably a little further out from implementation.  Might need to get Tom's input here.