July 30, 201510 yr A feature we are considering REMOVING at some point in the future of unRAID 6 would be that of spin up groups. This feature was originally designed to combat an issue specific to the use of IDE hard drives that are no longer prevalent in today's computers. The poll question here is to ascertain who, if anyone, is using this feature today and if so, for what purpose. Please provide your feedback and if you do use spin up groups, please let us know how they help you! Thanks!
July 30, 201510 yr dont use thm... even if someone would use them you could work around it by setting shares in such a way that media stays together and avoiding the issue..
July 30, 201510 yr I used to use them a few years ago when my music collection spanned two drives (2x 500G) Using spin up groups (the two drives in the same group) avoided long pauses if the next track was on the other drive. Appropriate split levels can avoid the need for spin up groups for most media, but for monster collections of music, you can wind up in an situation where the share must span two or more hard drives. However, this is lessened (but not eliminated) by todays hard drive sizes. As to whether or not you keep spin up groups, I am completely neutral on the subject. I used to use them. I no longer do. I can forsee certain use cases relying on them, but I can't personally foresee myself ever requiring them again.
July 30, 201510 yr How about replacing it with a new feature related to shares rather than hardware ports? IOW, if you check this setting on a share, then as soon as a file in the share is accessed, all drives that participate in that share are immediately spun up as well? That setting combined with spin down timers could cover almost any scenario I can think of.
July 30, 201510 yr How about replacing it with a new feature related to shares rather than hardware ports? IOW, if you check this setting on a share, then as soon as a file in the share is accessed, all drives that participate in that share are immediately spun up as well? That setting combined with spin down timers could cover almost any scenario I can think of. That seems a very good idea. I can't see myself ever needing the feature but it would cover the use case Squid has presented. Personally I've never used them and can't see myself doing so at any point in the future. As regards Squid's example. With larger and larger HDDs you'd need an awful lot of music even uncompressed to require spinning up two drives and I agree that split level does cover that eventuality.
July 30, 201510 yr With the size of drives now it makes far more sense to ballance the data itself now rather than waste disk spin ups
July 30, 201510 yr They are enabled but no idea if I am actually using them. Voted Yes but meaning Dunno.
July 30, 201510 yr How about replacing it with a new feature related to shares rather than hardware ports? IOW, if you check this setting on a share, then as soon as a file in the share is accessed, all drives that participate in that share are immediately spun up as well? You can already do that somewhat by assigning your own spin-up group(s) and having your media isolated by type.
July 30, 201510 yr I use them, but don't really care if they're eliminated. I have a couple backup shares that, when I'm using them, I do so fairly aggressively, so I have all of the disks in that share assigned to the same spin-up group. On the other hand, I would NOT want a "share-based" spinup (as suggested above), as all of my media shares are unrestricted WRT which drives they can use (except for the drives associated with the backup shares, which I exclude from media shares). I would not, for example, want 18 drives to spinup whenever I access my DVD's share
July 30, 201510 yr I do not use them. I agree with garrycase. I do not want all of my drives in a share to spin up when I access a share. I go through and clean my system to so that any files in a subdirectory in a top level share are on the same disk. The more drives that spin up, the more heat I have in the room.
July 31, 201510 yr How about replacing it with a new feature related to shares rather than hardware ports? IOW, if you check this setting on a share, then as soon as a file in the share is accessed, all drives that participate in that share are immediately spun up as well? You can already do that somewhat by assigning your own spin-up group(s) and having your media isolated by type. Yep, and if spin up groups as they are defined now are removed, then having the OPTION to turn on a user share group spin up would replace that function. I never suggested that spinning up all drives in a share would be a default setting.
July 31, 201510 yr How about replacing it with a new feature related to shares rather than hardware ports? IOW, if you check this setting on a share, then as soon as a file in the share is accessed, all drives that participate in that share are immediately spun up as well? You can already do that somewhat by assigning your own spin-up group(s) and having your media isolated by type. Yep, and if spin up groups as they are defined now are removed, then having the OPTION to turn on a user share group spin up would replace that function. I never suggested that spinning up all drives in a share would be a default setting. That option would be okay if it's a "by share" setting ... but I don't see it as an improvement over the spin-up groups that are implemented now. The key reason for spin-up groups was to prevent pauses/stuttering in a stream if a drive on the same controller channel was accessed and had to spin up -- not necessarily that the other drive was part of the album/movie that was streaming (although it could of course be used for that purpose, as Squid did). Note that this can also happen with some SATA controllers, so there are still cases where it's useful. My "vote" would be to keep the current feature ... but as I noted earlier I don't really care either way.
July 31, 201510 yr I did once upon a time when my music was spread across a couple of disks, that mistake has been corrected and now see no need for them
July 31, 201510 yr I did once upon a time when my music was spread across a couple of disks, that mistake has been corrected and now see no need for them That seems to be a common theme.
July 31, 201510 yr How about replacing it with a new feature related to shares rather than hardware ports? IOW, if you check this setting on a share, then as soon as a file in the share is accessed, all drives that participate in that share are immediately spun up as well? That setting combined with spin down timers could cover almost any scenario I can think of. Like this. I get pauses in playback on SageTV all the time if I don't have spinup groups installed and do a scan for new media. SageTV will read each existing media file (just a few bytes) to make sure it exists before deleting it from the database. If you are playing back a file at the same time it will pause while unRAID spins up the drive(s) that the scanner is currently trying to read from.
July 31, 201510 yr How about replacing it with a new feature related to shares rather than hardware ports? IOW, if you check this setting on a share, then as soon as a file in the share is accessed, all drives that participate in that share are immediately spun up as well? You can already do that somewhat by assigning your own spin-up group(s) and having your media isolated by type. Yep, and if spin up groups as they are defined now are removed, then having the OPTION to turn on a user share group spin up would replace that function. I never suggested that spinning up all drives in a share would be a default setting. Uhm, i was pointing out that feature is the current spinup groups. If i was Limetech and the option was the following, I'd select not change a thing as long as its current implimentation wasnt causing catrostrophic failures. 1) not change a thing 2) remove current spinup groups and reimpliment essentially the same exact thing but with even more restricted spinup groups 3) remove spinup groups
August 1, 201510 yr I'd agree with "not change a thing", as Bob's experience isn't by any means unique. Note that replacing it with a share-based spinup option doesn't resolve this, as the pauses/stuttering that are often seen aren't necessarily due to accesses within the same share -- but by an access to a disk that is on the same controller that needs to be spun up. This is NOT (as I noted earlier) restricted to IDE controllers ... it's not an uncommon behavior with SATA controllers as well.
August 2, 201510 yr and get rid of all spin up and spin down buttons. It is useless. Might be to you, but I use them quite a bit. So, not useless.
August 2, 201510 yr and get rid of all spin up and spin down buttons. It is useless. Might be to you, but I use them quite a bit. So, not useless. Ditto ... these are definitely useful.
August 2, 201510 yr and get rid of all spin up and spin down buttons. It is useless. Might be to you, but I use them quite a bit. So, not useless. Perhaps you can explain how you are using them, it would be beneficial to have an understanding.
August 2, 201510 yr I would also be curious how many of these use cases could be better handled with data disk balancing and some upstream bug reports to software vendors
August 2, 201510 yr and get rid of all spin up and spin down buttons. It is useless. Might be to you, but I use them quite a bit. So, not useless. Perhaps you can explain how you are using them, it would be beneficial to have an understanding. Spin down if I know I'm finished using the shares, so the drives don't have to run needlessly for 30 mins or more. Spin up to save time when shutting the server down, or if I'm going to be using Plex, so there's no delay when starting a movie or show. I basically have Dashboard open all the time, and preempt the server spinning up or down the drives. Spinup groups? Don't use them now, but I can see merit in them, so I say keep them.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.