On 4/27/2021 at 8:26 AM, ken-ji said:

 

Because of a weird speed issue where I now need to spin up my array before running parity checks etc. and my personal opinions about php,

I had to take up the bash challenge (this might even be sh compatible)

Only did the spin them all up one though.

#!/bin/bash
. /usr/local/emhttp/state/var.ini

curl --unix-socket /var/run/emhttpd.socket \
  --data-urlencode cmdSpinupAll=apply \
  --data-urlencode startState=$mdState \
  --data-urlencode csrf_token=$csrf_token \
  http://127.0.0.1/update

 

 

So I gave this a whirl in my profile.sh, and it works. But it spins up all 22 disks in my array and also the 2 Unassigned Devices disks I have, all at the same time. Unraid via the webui does a staggered spinup of 1 disk at a time. Is spinning up all 24 disks in my chassis at the same time safe? If not, is there a way to imitate the webui spinup?

It's identical to the webUI.  (It actually calls the webUI to do it)

2 hours ago, Squid said:

It's identical to the webUI.  (It actually calls the webUI to do it)

 

It's not. The webui spins up disks one at a time. The above bash code spins them all up at the same time. I can see the difference in power draw on my UPS, and the noise from the server is noticeably different as well. And as mentioned above, it also spins up my Unassigned Devices drives, which the normal webui spinup doesn't.

Edited July 14, 20214 yr by hasown

The bash code does exactly what clicking on the webui button does. the parameters are all taken from that.

Its been the same as far as i can tell.

8 minutes ago, ken-ji said:

The bash code does exactly what clicking on the webui button does. the parameters are all taken from that.

Its been the same as far as i can tell.

 

I have no experience in this, but inspecting the code in the webui for the spinup button shows the following onclick event. So at the very least it appears to me that the button is limiting the spinup to the array? The bash in this thread doesn't do that. And again, the webui button staggers the spinups, versus the bash in this thread which does it all at once. It's very noticeable if you have more than a few disks; you could easily reproduce it yourself, I would think, just by pressing the webui button and watching the disk states, and then spinning down the disks and trying the same thing with the script.

 

function onclick(event) {
  toggle_state('Device', 'array*', 'up')
}

 

come to think of it... the bash code is based on the php script earlier in the discussion.
maybe its not quite the same for current Unraid versions...

 

5 minutes ago, ken-ji said:

come to think of it... the bash code is based on the php script earlier in the discussion.
maybe its not quite the same for current Unraid versions...

 

That's my concern. To give some more solid numbers: when all my disks are spun down and I press the spinup button in the webui, my UPS slowly increases output from ~300w to ~420w over about 2-3 minutes. The disks stagger the spinup and the power draw is gradual. If I use the bash code, my UPS immediately jumps to ~700w because 24 hard disks are spinning up at once. Then the power decreases to the normal draw of ~420w.

 

My UPS and PSU can handle a 700w draw, but I think this code might be dangerous in its current state for people who don't have that extra power capacity in their servers.

Edited July 14, 20214 yr by hasown

I understand your point, but to provide a counterpoint. those people are running their server dangerously since you should never spec a system with such marginal power capacity - even if your Bios says drive spin up is staggered.

That said, my script spinning everything up at once might be why its giving me issues with performance during parity tests...

 

I'll look into this and add a bash snippet when I've figured this out.

3 minutes ago, ken-ji said:

I understand your point, but to provide a counterpoint. those people are running their server dangerously since you should never spec a system with such marginal power capacity - even if your Bios says drive spin up is staggered.

That said, my script spinning everything up at once might be why its giving me issues with performance during parity tests...

 

I'll look into this and add a bash snippet when I've figured this out.

 

Oh I understand that it's a dangerous way to spec a server; I would never do it myself. But I think the webui staggers it exactly to avoid this scenario out of an abundance of caution, so that's why I started posting in the thread. But thank you for the bash code as is and any future improvements.

22 minutes ago, hasown said:

I think this code might be dangerous in its current state for people who don't have that extra power capacity in their servers.

When an array disk read fails, Unraid immediately spins up all drives, calculates what the read should have returned, and attempts to write that value back to the disk with the failed read. So, any server running Unraid with spin down enabled must be capable of handling the sudden "all hands on deck" spin up.

11 hours ago, jonathanm said:

When an array disk read fails, Unraid immediately spins up all drives, calculates what the read should have returned, and attempts to write that value back to the disk with the failed read. So, any server running Unraid with spin down enabled must be capable of handling the sudden "all hands on deck" spin up.

 

Good to know. Regardless though, hopefully the code in this thread can eventually imitate the normal webui spinup instead of the emergency spinup.

Spending a little time reveals that the bash script is doing exactly the same thing as the WebUI
the webUI triggers this event

toggle_state(up)

which is a function that invokes this since it has no other parameters filled out

$.post('/webGui/include/ToggleState.php',{device:device,name:name,action:action,state:'STARTED',csrf:'REDACTED'},function(){resumeEvents(event,500);if (button) $(button).prop('disabled',false);});

which then invokes a curl to http://127.0.0.1/update

function emhttpd($cmd) {
  global $state, $csrf;
  $ch = curl_init("http://127.0.0.1/update");
  $options = array(CURLOPT_UNIX_SOCKET_PATH => '/var/run/emhttpd.socket',
                   CURLOPT_POST => 1,
                   CURLOPT_POSTFIELDS => "$cmd&startState=$state&csrf_token=$csrf");
  curl_setopt_array($ch, $options);
  curl_exec($ch);
  curl_close($ch);
}

the important point here is the cmd parameter which is set using the device query param as "up" thus triggering the same spin up all drives

default:
  if (!$name) {
    // spin up/down all devices
    emhttpd("cmdSpin{$device}All=true");
    break;
  }

 

And I double checked. Clicking the button spins up all my drives at the same time, versus when I try to access my data in the share which is spread out across all my drives.