February 22, 201511 yr That are great average speeds Thanks! I worked hard for those. I just realized a couple of things about my workaround, one minor, the other not: - that script could be improved slightly with a -q option to grep - emhttp is apparently exec'ing smartctl, and doesn't like it being a script as opposed to a binary executable. So I've broken my drive temperature readouts in the web GUI. I guess I'll put the real smartctl back in place and resort to manually moving it aside before a disk-heavy operation. Bummer. It does work with a small modif: Xsmartctl $* You need to pass the original parameters ... This issue is currently logged for further investigation and appropriate solution.
February 22, 201511 yr I had suggested to Tom a long time ago to cache the output of smartctl into /var/log/smart/model-serial. Then use the mtime of that file as a point in time to help limit how many 'true' smartctl's are executed per minute. I.E. using the mtime of the cached output, limit actual smartctl polling of the sata device to once every minute or three minute. Such as return cached value unless it is older then 1 or x number of minutes, then poll with smartctl, cache data and return cached data. Tom mentioned that if there is a problem, the temperature could rise very rapidly and he wanted to insure that data was visible. I suggested expanding the poll timer. He mentioned that was attached to the spindown timer and expanding that would delay spin downs by the poll value. I'm sure we could do something in the smartctl call out itself. Perhaps some batch method of adjusting Tunable (poll_spindown): via some php call. Perhaps some method of detecting a parity sync in the webGui/emhttp and expanding this automatically while the parity sync is in progress.
February 22, 201511 yr I just finished a parity check after I ran the unraid-tunables-tester on v6b14 and made the recommended settings changes. I got the following: Duration: 4 hours, 58 minutes, 18 seconds. Average speed: 111.8 MB/sec Not bad! I've never gotten this kind of speed on a parity check. I have 4 VMs running on a SSD cache drive, so there was disk activity that may have slowed down the parity check. All my disks are 2TB Reds. The last parity check I ran on V6 took about 7 hours.
February 22, 201511 yr Author It does work with a small modif: Xsmartctl $* You need to pass the original parameters ... This issue is currently logged for further investigation and appropriate solution. Oopsie . . . good catch! I'l try that next.
February 22, 201511 yr Author WeeboTech: Good to hear there are potential solutions being considered. Dlandon: Thanks for the tunables-tester data point; I'm pretty close to the theoretical bandwidth limit of my setup but it can't hurt to try!
February 22, 201511 yr WeeboTech: Good to hear there are potential solutions being considered. Frankly, I do not know if they are being considered. Those were points/options I made. It's still up to LT to choose to implement.
February 22, 201511 yr Author Frankly, I do not know if they are being considered. Those were points/options I made. It's still up to LT to choose to implement. Understood; thanks for the clarification. Beta10a doesn't have this problem yet still manages to report drive temperatures. Granted you have to refresh to get them, versus the automatic page updating that Dynamix provides. But say I were to disable that automatic page updating, there'd be no way to report a temperature problem without the user refreshing the page (setting aside the notification system). Yet even with automatic page updates disabled I still repeated/numerous smartctl invocations. Perhaps those are to serve the notification system. I have that turned off too (Notification entity: None) by the way. I guess bottom line what I'd like is a way to toggle the new 'repeated/numerous smartctl invocations' behavior *back* to the way it was in beta10a. There seems to be no way to do that currently despite my disengaging as many of the page updating and notification mechanisms I can find to disengage. In that mode we would have to live with only seeing temperature alarms if/when we update the page, but that's worked (at least for me) for going on four years now.
February 23, 201511 yr Frankly, I do not know if they are being considered. Those were points/options I made. It's still up to LT to choose to implement. Understood; thanks for the clarification. Beta10a doesn't have this problem yet still manages to report drive temperatures. Granted you have to refresh to get them, versus the automatic page updating that Dynamix provides. But say I were to disable that automatic page updating, there'd be no way to report a temperature problem without the user refreshing the page (setting aside the notification system). Yet even with automatic page updates disabled I still repeated/numerous smartctl invocations. Perhaps those are to serve the notification system. I have that turned off too (Notification entity: None) by the way. I guess bottom line what I'd like is a way to toggle the new 'repeated/numerous smartctl invocations' behavior *back* to the way it was in beta10a. There seems to be no way to do that currently despite my disengaging as many of the page updating and notification mechanisms I can find to disengage. In that mode we would have to live with only seeing temperature alarms if/when we update the page, but that's worked (at least for me) for going on four years now. Try temporarily adjusting the Tunable (poll_spindown): on the settings page to a higher value, then switch away from the pages that auto refresh and see if this helps. I do realize it's not the answer, it may help point to a potential solution.
February 23, 201511 yr Author Try temporarily adjusting the Tunable (poll_spindown): on the settings page to a higher value, then switch away from the pages that auto refresh and see if this helps. That definitely helped. I set it to 15 and confirmed that the raft of smartctl invocations changed to every 15 seconds instead of 10. I've got it set much higher now, I suspect I can specify something close to "never" by just using a ridiculously large number there (like 86400 for once a day). My observation is that it doesn't matter what page I'm looking at, the group of smartctl invocations keep coming at the specified interval, I'm guessing one per spun-up drive.
February 23, 201511 yr Try temporarily adjusting the Tunable (poll_spindown): on the settings page to a higher value, then switch away from the pages that auto refresh and see if this helps. That definitely helped. I set it to 15 and confirmed that the raft of smartctl invocations changed to every 15 seconds instead of 10. I've got it set much higher now, I suspect I can specify something close to "never" by just using a ridiculously large number there (like 86400 for once a day). My observation is that it doesn't matter what page I'm looking at, the group of smartctl invocations keep coming at the specified interval, I'm guessing one per spun-up drive. Too large a value like 86400 would have the effect of disabling spin down. These two tasks, temperature via smartctl and spin down look to be tied together. I might suggest a number like 180 or 300 and work from there, Worst case with those values spin down will be delayed by that amount.
February 23, 201511 yr Author Too large a value like 86400 would have the effect of disabling spin down. These two tasks, temperature via smartctl and spin down look to be tied together. I might suggest a number like 180 or 300 and work from there, Worst case with those values spin down will be delayed by that amount. Ah, I see. Good to know. I'm at 100 now, figuring that would cut the overhead by a factor of 10, so if I was losing 10% throughput to it before, I'd be at more like 1% now. I'm sure that's an oversimplification; when I next run a Parity Check I can get a better idea how accurate that theory is. With that setting then my spin-downs would happen somewhere between 900 and 1000 seconds after the last access instead of 900 and 910 (I'm set to 15 minutes on this server); I can live with that. I've learned more about unRAID in the last few days than I had in the preceding 3+ years of use!
Archived
This topic is now archived and is closed to further replies.