unRAID Server release 4.5-beta12 available

I'm also of the opinion the SpinUp Groups are enabled by default. It's a better user experience since it eliminates potential 'freezes'.

I also would like to put my vote in for having the SpinUp Groups enabled by default.  The whole point of it is to improve the user experience and this will help to solve some of the freezing problems reported by users.

 

A checkbox to disable this would be nice and make for cleaner presentation and easier process of turning it off if someone wishes not to use it.

Thanks for the clarification.  After breaking my USB drive ( leaning into it ),  I've learned to always keep a backup of my flash drive contents

 

As its so easy to upgrade and their has been many improvements ( and continue to be ), I guess going with Beta12 is the best thing to do.

 

Once I finish preclearing my drive being added, i will do the update. 

 

 

Thanks

Personally I'd like to see each user-share having the ability to spin up its collection of affiliated drives.  In effect, I'd like each user-share to be able to have feature to enable/disable spin-up of ALL the drives it uses when accessed.   Yes, in my case it would mean spinning up all the drives when I start to scan the Movies share.   It would make use of the media clients on the LAN the easiest for me and my family, all to deal with the media player limitations and timeout issues where I have far less control.

 

I'd like this, too. However, I'd prefer if only those disks span up which need to spin up to avoid a "chained" delay. Basically, if browsing a share needs spinning up of 5 disks out of 10, then currently I need to wait until those 5 disks have spun up, one after the other. Your suggestion would result in spinning up all 10 disks at once. That'd be better than the current situation. But personally, I'd prefer if only those 5 needed disks would spin up (at once). Don't know if that's possible to realize, though.

 

Personally, due to using a HTPC, I have no problem with the delay caused by waiting for *one* disk to spin up. However, I run into problems if I have to wait for multiple disks to spin up, one after the other...

Personally I'd like to see each user-share having the ability to spin up its collection of affiliated drives.  In effect, I'd like each user-share to be able to have feature to enable/disable spin-up of ALL the drives it uses when accessed.   Yes, in my case it would mean spinning up all the drives when I start to scan the Movies share.   It would make use of the media clients on the LAN the easiest for me and my family, all to deal with the media player limitations and timeout issues where I have far less control.

 

I'd like this, too. However, I'd prefer if only those disks span up which need to spin up to avoid a "chained" delay. Basically, if browsing a share needs spinning up of 5 disks out of 10, then currently I need to wait until those 5 disks have spun up, one after the other. Your suggestion would result in spinning up all 10 disks at once. That'd be better than the current situation. But personally, I'd prefer if only those 5 needed disks would spin up (at once). Don't know if that's possible to realize, though.

 

Personally, due to using a HTPC, I have no problem with the delay caused by waiting for *one* disk to spin up. However, I run into problems if I have to wait for multiple disks to spin up, one after the other...

 

The kind of behavior you want is possible to do now, though you have to manually set it up.  First identify the set of disks being used by the user share for which you want all disks to spinup upon access to any of them.  Let's say this is disk1, disk2, and disk4.

 

Next, click on each of those links from the Main webGui page.  You will see there is already a controller spinup group defined, e.g., 'host6'.  Just add an additional spinup group name to that field.

 

Let's say you want to name the group 'movies'.  Then just add the string 'movies' to the list of spinup groups (separated by a space).  So let's say for disk1 the current spinup group is this:

 

Spinup groups(s):   host6

 

Just add 'movies' to this and click Apply:

 

Spinup groups():    host6 movies

 

Do this for all the disks that you want to have spinup together (disk1, disk2, and disk4 in our example).

 

At present time this procedure is manual, i.e., you have to figure out which disks to do this with on your own and then program each disk's Spinup group(s) field.  This feature will evolve over time, for example, I can add a checkbox with each share that says, "generate spinup group for this share".  But I have to stop implementing features and get 4.5-final done - so this is where I'm drawing the line for the 4.5 series.

Personally I'd like to see each user-share having the ability to spin up its collection of affiliated drives.  In effect, I'd like each user-share to be able to have feature to enable/disable spin-up of ALL the drives it uses when accessed.   Yes, in my case it would mean spinning up all the drives when I start to scan the Movies share.   It would make use of the media clients on the LAN the easiest for me and my family, all to deal with the media player limitations and timeout issues where I have far less control.

 

I'd like this, too. However, I'd prefer if only those disks span up which need to spin up to avoid a "chained" delay. Basically, if browsing a share needs spinning up of 5 disks out of 10, then currently I need to wait until those 5 disks have spun up, one after the other. Your suggestion would result in spinning up all 10 disks at once. That'd be better than the current situation. But personally, I'd prefer if only those 5 needed disks would spin up (at once). Don't know if that's possible to realize, though.

 

Personally, due to using a HTPC, I have no problem with the delay caused by waiting for *one* disk to spin up. However, I run into problems if I have to wait for multiple disks to spin up, one after the other...

 

The kind of behavior you want is possible to do now, though you have to manually set it up.  First identify the set of disks being used by the user share for which you want all disks to spinup upon access to any of them.  Let's say this is disk1, disk2, and disk4.

 

Next, click on each of those links from the Main webGui page.  You will see there is already a controller spinup group defined, e.g., 'host6'.  Just add an additional spinup group name to that field.

 

Let's say you want to name the group 'movies'.  Then just add the string 'movies' to the list of spinup groups (separated by a space).  So let's say for disk1 the current spinup group is this:

 

Spinup groups(s):   host6

 

Just add 'movies' to this and click Apply:

 

Spinup groups():    host6 movies

 

Do this for all the disks that you want to have spinup together (disk1, disk2, and disk4 in our example).

 

At present time this procedure is manual, i.e., you have to figure out which disks to do this with on your own and then program each disk's Spinup group(s) field.  This feature will evolve over time, for example, I can add a checkbox with each share that says, "generate spinup group for this share".  But I have to stop implementing features and get 4.5-final done - so this is where I'm drawing the line for the 4.5 series.

I completely understand the need to finalize the 4.5 series.  I think you've done a great job of tracking down the various causes of the "freeze" of data... or at least those you know of... so far... 

 

Putting "movies" in all the disks as a spin-up group would work if I had nothing else on my server.  For example, I have music files, but only on a few disks, in the same way, I have pictures, but only on a few disks.

 

The preference would be to know that the "Movies" share was being accessed and to spin up its set of disks (which in my case is all of them) but to only spin up the few disks with music, or the few with pictures when the "Pictures" share was accessed. 

 

For some subsequent release... after you get 4.5final out the door, please consider a feature where on the user-shares page, each "share" could have a checkbox to enable spinning up the group of disks affiliated with that share at a single time any one is enabled... Or, a field to specify the set of disks to spin up when the share is enabled. (The former seems to be more automatic and needing less user-interaction to figure out where the data is being stored based on the new files added and share allocation rules.  The latter is more likely to get out of date as the files are moved around and new ones added.)

 

Personally, I like it simple...  one checkbox per user-share to spin them up as a group would work for me.

 

Joe L.

Personally I'd like to see each user-share having the ability to spin up its collection of affiliated drives.  In effect, I'd like each user-share to be able to have feature to enable/disable spin-up of ALL the drives it uses when accessed.   Yes, in my case it would mean spinning up all the drives when I start to scan the Movies share.   It would make use of the media clients on the LAN the easiest for me and my family, all to deal with the media player limitations and timeout issues where I have far less control.

 

I'd like this, too. However, I'd prefer if only those disks span up which need to spin up to avoid a "chained" delay. Basically, if browsing a share needs spinning up of 5 disks out of 10, then currently I need to wait until those 5 disks have spun up, one after the other. Your suggestion would result in spinning up all 10 disks at once. That'd be better than the current situation. But personally, I'd prefer if only those 5 needed disks would spin up (at once). Don't know if that's possible to realize, though.

 

Personally, due to using a HTPC, I have no problem with the delay caused by waiting for *one* disk to spin up. However, I run into problems if I have to wait for multiple disks to spin up, one after the other...

 

The kind of behavior you want is possible to do now, though you have to manually set it up.  First identify the set of disks being used by the user share for which you want all disks to spinup upon access to any of them.  Let's say this is disk1, disk2, and disk4.

 

Next, click on each of those links from the Main webGui page.  You will see there is already a controller spinup group defined, e.g., 'host6'.  Just add an additional spinup group name to that field.

 

Let's say you want to name the group 'movies'.  Then just add the string 'movies' to the list of spinup groups (separated by a space).  So let's say for disk1 the current spinup group is this:

 

Spinup groups(s):   host6

 

Just add 'movies' to this and click Apply:

 

Spinup groups():    host6 movies

 

Do this for all the disks that you want to have spinup together (disk1, disk2, and disk4 in our example).

 

At present time this procedure is manual, i.e., you have to figure out which disks to do this with on your own and then program each disk's Spinup group(s) field.  This feature will evolve over time, for example, I can add a checkbox with each share that says, "generate spinup group for this share".  But I have to stop implementing features and get 4.5-final done - so this is where I'm drawing the line for the 4.5 series.

I completely understand the need to finalize the 4.5 series.   I think you've done a great job of tracking down the various causes of the "freeze" of data... or at least those you know of... so far... 

 

Putting "movies" in all the disks as a spin-up group would work if I had nothing else on my server.  For example, I have music files, but only on a few disks, in the same way, I have pictures, but only on a few disks.

 

The preference would be to know that the "Movies" share was being accessed and to spin up its set of disks (which in my case is all of them) but to only spin up the few disks with music, or the few with pictures when the "Pictures" share was accessed. 

 

For some subsequent release... after you get 4.5final out the door, please consider a feature where on the user-shares page, each "share" could have a checkbox to enable spinning up the group of disks affiliated with that share at a single time any one is enabled... Or, a field to specify the set of disks to spin up when the share is enabled. (The former seems to be more automatic and needing less user-interaction to figure out where the data is being stored based on the new files added and share allocation rules.  The latter is more likely to get out of date as the files are moved around and new ones added.)

 

Personally, I like it simple...  one checkbox per user-share to spin them up as a group would work for me.

 

Joe L.

 

If the shares occupied disjoint sets of disks, you could do this functionality now manually.  For example, if diskA,B,C only contained movies, you could put them in a 'movies' group; and, if diskD,E only contained music, you could put in 'music' group, etc.  When a disk has multiple shares on it, then it requires more code, which I will leave for another release cycle.

Let's say you want to name the group 'movies'.  Then just add the string 'movies' to the list of spinup groups (separated by a space).  So let's say for disk1.....

Just add 'movies' to this and click Apply:

 

At present time this procedure is manual, i.e., you have to figure out which disks to do this with on your own and then program each disk's Spinup group(s) field.  This feature will evolve over time, for example, I can add a checkbox with each share that says, "generate spinup group for this share".  But I have to stop implementing features and get 4.5-final done - so this is where I'm drawing the line for the 4.5 series.

 

How does the list of spin up groups get communicated with the md driver?

Does emhttp send some command down /proc/mdcmd that identifies a drive with a spin up group?

 

I ask to see if an external application can define these through what ever inspection is needed (i.e. automatic disk -> user share definition or usershare -> disk spin up group definition. )

Let's say you want to name the group 'movies'.  Then just add the string 'movies' to the list of spinup groups (separated by a space).  So let's say for disk1.....

Just add 'movies' to this and click Apply:

 

At present time this procedure is manual, i.e., you have to figure out which disks to do this with on your own and then program each disk's Spinup group(s) field.  This feature will evolve over time, for example, I can add a checkbox with each share that says, "generate spinup group for this share".  But I have to stop implementing features and get 4.5-final done - so this is where I'm drawing the line for the 4.5 series.

 

How does the list of spin up groups get communicated with the md driver?

Does emhttp send some command down /proc/mdcmd that identifies a drive with a spin up group?

Yes.  If you look at the syslog you'll see a series of

mdcmd spinup_group

commands.  The format of this command is:

mdcmd set spinup_group <slot> <mask>

where <slot> corresponds to disk# (0 means parity), and <mask> is a bitmask of other disks which should spinup when this disk receives an I/O (and those other disk(s) are spundown).  Bit 0 of mask corresponds to disk0, ie, parity.  Bitmask should not include the corresponding bit for the disk the command is sent for.  The emhttp process sends these commands down to the driver upon startup, and any time spinup groups are changed via webGui.  The md driver determines whether a disk is spun up/down based on it receiving

mdcmd spinup <slot>

and

mdcmd spindown <slot>

commands - that is it does not determine this by explicitly polling the drive (that would kill performance).  You can go look at function md_make_request() in md.c source file for the gory details.

Personally I'd like to see each user-share having the ability to spin up its collection of affiliated drives.  In effect, I'd like each user-share to be able to have feature to enable/disable spin-up of ALL the drives it uses when accessed.  Yes, in my case it would mean spinning up all the drives when I start to scan the Movies share.  It would make use of the media clients on the LAN the easiest for me and my family, all to deal with the media player limitations and timeout issues where I have far less control.

 

I'd like this, too. However, I'd prefer if only those disks span up which need to spin up to avoid a "chained" delay. Basically, if browsing a share needs spinning up of 5 disks out of 10, then currently I need to wait until those 5 disks have spun up, one after the other. Your suggestion would result in spinning up all 10 disks at once. That'd be better than the current situation. But personally, I'd prefer if only those 5 needed disks would spin up (at once). Don't know if that's possible to realize, though.

 

Personally, due to using a HTPC, I have no problem with the delay caused by waiting for *one* disk to spin up. However, I run into problems if I have to wait for multiple disks to spin up, one after the other...

 

The kind of behavior you want is possible to do now, though you have to manually set it up.

 

No. That's not the behaviour I'm looking for. Let me try to explain:

 

I've a user share covering all of my data disks. Now in the morning, when all disks are spun down, if I access this user share, some of the disks spin up and some don't. I don't know why only some spin up and others don't. But that's the way it has always been for me. JoeL's cache script has improved the situation (I think), but not fully solved it. Now what I'd like to have is basically the same behaviour as it is right now, but with less wasted time. Basically I *don't* want all disks to spin up everytime I access the share. I just want to get rid of situations where multiple disks spin up, one slowly after the other. I'd like unRAID to detect situations where this happens and to spin up all the affected disks (but only the affected disks) at the same time.

 

Example, current situation:

 

- All of my 9 disks are spun down.

- I browse that user share, covering all 9 disks.

- disk 1 spins up -> 7 seconds pass by

- disk 2 spins up -> 7 more seconds pass by

- disk 5 spins up -> 7 more seconds pass by

- the other disks keep sleeping

 

Example, wanted behaviour:

 

- All of my 9 disks are spun down.

- I browse that user share, covering all 9 disks.

- disk 1, 2 and 5 spin up at the same time -> 7 seconds pass by

- the other disks keep sleeping

Example, current situation:

 

- All of my 9 disks are spun down.

- I browse that user share, covering all 9 disks.

- disk 1 spins up -> 7 seconds pass by

- disk 2 spins up -> 7 more seconds pass by

- disk 5 spins up -> 7 more seconds pass by

- the other disks keep sleeping

 

Example, wanted behaviour:

 

- All of my 9 disks are spun down.

- I browse that user share, covering all 9 disks.

- disk 1, 2 and 5 spin up at the same time -> 7 seconds pass by

- the other disks keep sleeping

 

How is unraid to know that only disks 1, 2 & 5 need to be spun up?

 

My guess is that your SMB client is requesting something on disk1, once it gets it, waiting for something off disk 2, and so on.  Unraid wont know to spin up disk 2 until the client requests something from it, and from the sound of it, the client isn't requesting it until after it completes the request from disk 1.

 

Maybe this delay in requests is related to the "Windows client only using one SMB connection for multiple sessions" issue?  Has anyone verified that using NFS on a windows client gets around this blocking issue?

 

I'm a little unsure of where to post this, since we've moved on to Beta 13 and the issue may be hardware, not B12 related.  Sorry if I get this wrong.  One of the reasons I'm posting this in the B12 thread is that another user had the same error up above (Tower kernel: ata20.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0) which is leading to parity write errors on my server.

 

This issue was not apparent on B7 (and I have not yet reverted to B7 to see if it goes away), and it began the very first time I booted B12.

 

My Parity drive is now giving errors that are causing it to become disabled.  On B12, I no longer have parity.  The very first time I booted on B12, it didn't recognize parity and forced me to run a parity sync to start the array.  After it completed, the parity drive button color was still red, and I realized there were errors.  I rebooted and tried again to create the parity.  Here's the odd part:  It gets through approximately 75% of the drive before there was any errors.  My parity drive is 2 TB, and my largest data drive is 1.5 TB.  So it seems to be getting through all the data drive parity creation before erroring.  This, of course, is probably just a coincidence, but I didn't want to leave any detail out.  Speaking of detail, I've had occasional errors that get corrected by parity checks since day one (a few months ago), but it has never disabled parity before.

 

I've attached the log file with errors. 

 

Here's the SMART report for the parity drive:

Statistics for /dev/sdo WDC_WD2002FYPS-01U1B0_WD-WCAVY0102731

smartctl version 5.38 [i486-slackware-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF INFORMATION SECTION ===
Device Model:     WDC WD2002FYPS-01U1B0
Serial Number:    WD-WCAVY0102731
Firmware Version: 04.05G04
User Capacity:    2,000,398,934,016 bytes
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   8
ATA Standard is:  Exact ATA specification draft version not indicated
Local Time is:    Sat Dec  5 11:09:08 2009 EST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x84)	Offline data collection activity
				was suspended by an interrupting command from host.
				Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0)	The previous self-test routine completed
				without error or no self-test has ever 
				been run.
Total time to complete Offline 
data collection: 		 (41160) seconds.
Offline data collection
capabilities: 			 (0x7b) SMART execute Offline immediate.
				Auto Offline data collection on/off support.
				Suspend Offline collection upon new
				command.
				Offline surface scan supported.
				Self-test supported.
				Conveyance Self-test supported.
				Selective Self-test supported.
SMART capabilities:            (0x0003)	Saves SMART data before entering
				power-saving mode.
				Supports SMART auto save timer.
Error logging capability:        (0x01)	Error logging supported.
				General Purpose Logging supported.
Short self-test routine 
recommended polling time: 	 (   2) minutes.
Extended self-test routine
recommended polling time: 	 ( 255) minutes.
Conveyance self-test routine
recommended polling time: 	 (   5) minutes.
SCT capabilities: 	       (0x303f)	SCT Status supported.
				SCT Feature Control supported.
				SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   197   197   051    Pre-fail  Always       -       41708
  3 Spin_Up_Time            0x0027   164   155   021    Pre-fail  Always       -       8791
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       452
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   200   200   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   095   095   000    Old_age   Always       -       3667
10 Spin_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
11 Calibration_Retry_Count 0x0032   100   100   000    Old_age   Always       -       0
12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       192
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       90
193 Load_Cycle_Count        0x0032   196   196   000    Old_age   Always       -       14697
194 Temperature_Celsius     0x0022   127   107   000    Old_age   Always       -       25
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   196   196   000    Old_age   Always       -       1462
198 Offline_Uncorrectable   0x0030   196   196   000    Old_age   Offline      -       1326
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       1
200 Multi_Zone_Error_Rate   0x0008   183   169   000    Old_age   Offline      -       3580

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]


SMART Selective self-test log data structure revision number 1
SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

 

I tried running both the SHORT and LONG SMART tests, but clicking the button in unMENU under B12 don't seem to do anything.

 

As far as next steps, I plan to try using different slots for the parity drive, to rule out cable and controller related issues (current controler is on the motherboard (ASUS A379T Deluxe, SB700 in AHCI mode) and alternate controller I will try is an Adaptec 1430SA).  I also plan to try IDE mode, different hard drives, and possibly Beta7 again.  Unfortunately, it takes about a day to perform each test.

 

Is there any possibility that this is not a hardware issue and is B12 related?  Thanks in advance for any help and insight.

Example, current situation:

- All of my 9 disks are spun down.

- I browse that user share, covering all 9 disks.

- disk 1 spins up -> 7 seconds pass by

- disk 2 spins up -> 7 more seconds pass by

- disk 5 spins up -> 7 more seconds pass by

- the other disks keep sleeping

 

Example, wanted behaviour:

 

- All of my 9 disks are spun down.

- I browse that user share, covering all 9 disks.

- disk 1, 2 and 5 spin up at the same time

 

Drives spin up one after another for a good reason.  Spinning up a drive is the time when it draws most power.  Imagine the spike if all your drives were to spin up at the same time.  No power supply would survive that.

 

Purko

 

 

Drives spin up one after another for a good reason.  Spinning up a drive is the time when it draws most power.  Imagine the spike if all your drives were to spin up at the same time.  No power supply would survive that.

Purko

 

I second this suggestion, every time when i stop my unRaid, this stopping will bring up all spun down drives and the sound of those drive spin up simultaneously is really scary as if all those drivers are struggling to come up. We should have a method to bring up each one of them in sequence.

Imagine the spike if all your drives were to spin up at the same time.  No power supply would survive that.

 

I disagree here. The power supply in my unraid server handles it just fine.  In my rack/cabinet, I need to stagger spin-up in all servers to avoid blowing a 30amp breaker if the entire cabinet powers up at one time (only happens if my provider has done something terrible, resulting in my cabinet being powered down), but the individual power supplies in each server can, and should, easily take the load of all disks spinning up at once.

 

You need to use a better power supply if your system can't handle the spin-up.

 

every time when i stop my unRaid, this stopping will bring up all spun down drives

 

That's because of the linux sync command (which is part of the shutdown process) ... not unRAID.

Imagine the spike if all your drives were to spin up at the same time.  No power supply would survive that.

 

I disagree here. The power supply in my unraid server handles it just fine.  In my rack/cabinet, I need to stagger spin-up in all servers to avoid blowing a 30amp breaker if the entire cabinet powers up at one time (only happens if my provider has done something terrible, resulting in my cabinet being powered down), but the individual power supplies in each server can, and should, easily take the load of all disks spinning up at once.

 

You need to use a better power supply if your system can't handle the spin-up.

 

 

I'm also thinking that staggered spin up is not necessary with a moderately sized power supply.  I'm running a Corsair CX400W http://www.corsair.com/products/cx/default.aspx (i.e. a "small" by today's standards 400W supply - just try buying something smaller at your local computer shop!) and the spec for it lists the 12V line as capable of 30A.  From the WD green drive spec sheets ( http://www.wdc.com/wdproducts/library/SpecSheet/ENG/2879-701229.pdf ) it looks like the start up max 12V current is a 1.76A, so starting 10 of these at once you're looking at 18A which is safely below the 30A maximum.  Once these drives are running they are taking less that 0.5A each.

 

So maybe there should be an option on each spinup group to choose between spinning up everything at once or sequentially, or this could be a global setting, like: "maximum number of drives to spin up at once", it would default to 1 and those who have the power could raise it.

 

Regards,

 

Stephen

 

Example, current situation:

- All of my 9 disks are spun down.

- I browse that user share, covering all 9 disks.

- disk 1 spins up -> 7 seconds pass by

- disk 2 spins up -> 7 more seconds pass by

- disk 5 spins up -> 7 more seconds pass by

- the other disks keep sleeping

 

Example, wanted behaviour:

 

- All of my 9 disks are spun down.

- I browse that user share, covering all 9 disks.

- disk 1, 2 and 5 spin up at the same time

 

Drives spin up one after another for a good reason.  Spinning up a drive is the time when it draws most power.  Imagine the spike if all your drives were to spin up at the same time.  No power supply would survive that.

 

Purko

 

 

 

So what happens when you power the machine on?  They all spin up at once right?  Your PSU handles it fine.

I disagree here. The power supply in my unraid server handles it just fine.

Yes, it handles them just fine, EXACTLY because they don't spin up at the same time!

every time when i stop my unRaid, this stopping will bring up all spun down drives

 

That's because of the linux sync command (which is part of the shutdown process) ... not unRAID.

 

 

Well, how about unRAID just spin up ALL drives first, one after the other then issue sync command to

flush all pending data? 

every time when i stop my unRaid, this stopping will bring up all spun down drives

 

That's because of the linux sync command (which is part of the shutdown process) ... not unRAID.

 

 

Well, how about unRAID just spin up ALL drives first, one after the other then issue sync command to

flush all pending data? 

 

That's exactly what it does.

 

That's exactly what it does.

 

It looks like, but does unRaid will not spin up next one until current one up to speed?

If Unraid can control this operation then it will not draw too much power on PSU.

 

My 15 disks unRaid could draw as many as 380+ Watt during power up time observed from kill-a-watt meter.

 

Yes, it handles them just fine, EXACTLY because they don't spin up at the same time!

 

Actually, they do all spin up at the same time in my unraid system.

 

 

That's exactly what it does.

 

It looks like, but does unRaid will not spin up next one until current one up to speed?

If Unraid can control this operation then it will not draw too much power on PSU.

 

My 15 disks unRaid could draw as many as 380+ Watt during power up time observed from kill-a-watt meter.

 

 

Your system should be designed to be able to spin up all drives simultaneously.  This is what happens at startup (they all spin up).  Another time this could happen is if there is an unrecoverable I/O error during read/write.  In this case, driver will access all 'other' drives plus parity in order to reconstruct missing data on-the-fly, causing them to spinup if need be.

 

Staggered spinup is something that can be added in the future.

 

Time to close this thread.

Example, current situation:

 

- All of my 9 disks are spun down.

- I browse that user share, covering all 9 disks.

- disk 1 spins up -> 7 seconds pass by

- disk 2 spins up -> 7 more seconds pass by

- disk 5 spins up -> 7 more seconds pass by

- the other disks keep sleeping

 

Example, wanted behaviour:

 

- All of my 9 disks are spun down.

- I browse that user share, covering all 9 disks.

- disk 1, 2 and 5 spin up at the same time -> 7 seconds pass by

- the other disks keep sleeping

 

How is unraid to know that only disks 1, 2 & 5 need to be spun up?

 

My guess is that your SMB client is requesting something on disk1, once it gets it, waiting for something off disk 2, and so on.  Unraid wont know to spin up disk 2 until the client requests something from it, and from the sound of it, the client isn't requesting it until after it completes the request from disk 1.

 

The spinup occurs when just reading the directory tree. The SMB client is not requesting anything funny, but just the directory listing. So it can't be an SMB client problem. (And yes, I do have JoeL's cache script running.)

 

I'm not sure if unRAID can possibly know which disks need to be spun up and which don't. I don't know enough about the unRAID driver internals to answer that. But I can say that this "chained" spinup is the biggest (and only?) problem I have with unRAID. So I hope that some day there will be a reliably working solution for that...