unRAID Server release 4.5-beta12 available


limetech

Recommended Posts

The problem you will see with this release is that your spun-down array drives will spin back up as soon as you refresh the webGui screen because it will try and get the temperatures.

 

Hmmm.... That's not cool.  It shouldn't be too hard to check the drive status with "hdparm -C" or something before taking any temperatures.  And, the refresh from the webGui is a good time to sync the driver's idea about the drive status with real life.

 

Purko

 

Let's try this again... I'll take a look at this and add some code that can take into account external spinning status changes.

Link to comment
  • Replies 105
  • Created
  • Last Reply

Top Posters In This Topic

you're trying to tell him to fix something that isn't his issue, nor a problem.  You're using a script that isn't supported by Tom...

 

speeding_ant, we are talking about a change in behavior which occured between 4.5-beta11 and 4.5-beta12.  In my view, this change is undesirable, and fixable.

 

And yes, it can be a problem when the unRAID driver loses touch with reality.  My script is not an issue here.  None of the scripts people are running on their servers are supported by Tom.  The change in question brings an extra degree of messiness, and can break a lot of things for other people.

 

Purko

Respectfully, I can understand your dismay at having to deal with change, but it is obvious to me the change is not one that affects that many operations.  as already said, you can easily fix your script as unRAID evolves... and so will anybody else who has written an add-on script...  Myself included.

 

If, by chance, unRAID thinks a drive is spinning when it is not, then it will not spin it up as part of a spinup-group when another member of the group is accessed.  If the idle drive is spun up while the paired mate on the controller is being used, you'll just get the exact same delay as we've had for the past 5 years.  If the drive is already spinning, and emhttp thinks it is not, the display will be out-of-sync, and it will not spin it down until it thinks it is spinning and idle for whatever lts spin-down setting is configured for, but no effect on data flow or storage.

 

From what Tom has posted, you can determine unRAID's idea of a drive's spinning status by looking at the output  of a "mdcmd status" command.

 

If  rdevLastIO.X=0, the drive is not spinning.  If rdevLastIO.X>0, then drive X is spinning.  This make it very easy for the display of any add-on to be in sync.

(potentially wrong if you issued a hdparm command of your own, or accessed the drive through its raw partition without going through the"md" device, but in sync  ;D)

 

I'll make the changes to unMENU over the next day or so.  Until then, possibly expect an out-of-sync condition if you use its buttons to spin up or down the drives. 

 

Joe L.

Link to comment
I'll take a look at this and add some code that can take into account external spinning status changes.

 

Thank you!  :)

 

---

Now, just to clarify something...

I was more like thinking about simplifying some code, in case there's a setting somewhere that says "Never" bother to spin disks up or down.

In that case the driver will only care about a disks's state before taking it's temperature for a webGui refresh.

 

Link to comment

Thanks for the new release! Two questions:

 

3. An I/O stream via Windows PC freezes when same Windows PC is used to access data on a spundown disk.  This is a Windows problem and can not be fixed by unRAID OS.

 

Does this problem only apply to SMB? Would it help if I installed some NFS client on my Windows PC and used NFS instead of SMB to access unRAID shares?

 

In order to keep track of spinup groups and drive spinup status, this state info is maintained in the unRAID driver (because the driver needs to spin up drives based on incoming I/O requests)

 

This makes me wonder: Now that the driver controls spin up/down, could you make it more clever? E.g. it sometimes happens now that when I access a user share, that one disk spins up after the other, and it takes literally a minute or two until all disks are finally spun up. Would it be possible for the unRAID driver to "guess" that this is about to happen and to spin up all needed drives at once, just like the "spin up all drives" button on the HTTP site does?

Link to comment

Just wanted to say that while I only watched a couple of 45-minute TV shows last night, I did not experience any of the pausing video issues that having been plaguing me for at least a year.  Before last night, the first video we would watch (whether it was TV or a full-length movie) would always experience the pause within the first 15-30 seconds and at least once more before it finished (usually two or three times).

 

I did not monitor which drives spun up or anything due to the new spinup groups, I just watched as I normally do...the first time without any annoying pauses :]

 

I know that may be too early to call it fixed, but the simple fact that I didn't experience it even once excites me.

Link to comment

In order to keep track of spinup groups and drive spinup status, this state info is maintained in the unRAID driver (because the driver needs to spin up drives based on incoming I/O requests)

 

This makes me wonder: Now that the driver controls spin up/down, could you make it more clever? E.g. it sometimes happens now that when I access a user share, that one disk spins up after the other, and it takes literally a minute or two until all disks are finally spun up. Would it be possible for the unRAID driver to "guess" that this is about to happen and to spin up all needed drives at once, just like the "spin up all drives" button on the HTTP site does?

 

Since there is the ability to alter the drive groups, I suppose there is a way to segregate user shares to specific drives and set them as part of the drive group.  This could achieve what you want albeit at a slightly more involved set up process.

 

Perhaps later in the game the user share file system could be enhanced to know which drives are involved in a user share thus sending spin up commands to the md drive for all related drives. I'm sure there would be others who would not like this approach. There is already the dir_cache program to help prevent this. In addition, if those doing a write, do not want every drive spinning up just to find free space.

 

Who knows maybe this triggered spin control behavior based on user shares could be achieved by a third party monitor application if the md drive reports when it spins up and spins down drives.

Link to comment

Boot Problem!  I was running 4.5b6; copied bzimage and bzroot from 4.5b12 to Lexar 512MB flash drive.  Stopped the array and rebooted.  Got this error message:  SYSLINUX 3.51 2007-06-10 CBIOS Load Error - boot error.  I tried to recopy the bzimage and bzroot files from 4.5b6 to the flash to return to former files but I still get the same error message.  Cleared CMOS, etc and still get same error message.  I have the P5B-VM-DO MB, 4GB RAM, parity + 11 data drives (12 total HDD).  What do I do now?

Link to comment

Boot Problem!  I was running 4.5b6; copied bzimage and bzroot from 4.5b12 to Lexar 512MB flash drive.  Stopped the array and rebooted.  Got this error message:  SYSLINUX 3.51 2007-06-10 CBIOS Load Error - boot error.  I tried to recopy the bzimage and bzroot files from 4.5b6 to the flash to return to former files but I still get the same error message.  Cleared CMOS, etc and still get same error message.  I have the P5B-VM-DO MB, 4GB RAM, parity + 11 data drives (12 total HDD).  What do I do now?

 

Last time I ran into this, it ended up being a bad flash drive.

Link to comment

In order to keep track of spinup groups and drive spinup status, this state info is maintained in the unRAID driver (because the driver needs to spin up drives based on incoming I/O requests)

 

This makes me wonder: Now that the driver controls spin up/down, could you make it more clever? E.g. it sometimes happens now that when I access a user share, that one disk spins up after the other, and it takes literally a minute or two until all disks are finally spun up. Would it be possible for the unRAID driver to "guess" that this is about to happen and to spin up all needed drives at once, just like the "spin up all drives" button on the HTTP site does?

 

Since there is the ability to alter the drive groups, I suppose there is a way to segregate user shares to specific drives and set them as part of the drive group.  This could achieve what you want albeit at a slightly more involved set up process.

 

Perhaps later in the game the user share file system could be enhanced to know which drives are involved in a user share thus sending spin up commands to the md drive for all related drives. I'm sure there would be others who would not like this approach. There is already the dir_cache program to help prevent this. In addition, if those doing a write, do not want every drive spinning up just to find free space.

 

Who knows maybe this triggered spin control behavior based on user shares could be achieved by a third party monitor application if the md drive reports when it spins up and spins down drives.

 

One possibility for "guessing" the drives to spin up; if a file in an outer most branch of a user share (in a folder with no child folders) is accessed, and more files in that folder exist on other drives (say, a VIDEO_TS folder from a DVD spanned over many drives), you could then guess that the other files may be needed, and spin up the other disks.  Problem here is that you need the full directory structure from each disk in a user share cached to do this -- and there are many cases that it would "guess wrong".

 

Link to comment

Boot Problem!  I was running 4.5b6; copied bzimage and bzroot from 4.5b12 to Lexar 512MB flash drive.  Stopped the array and rebooted.  Got this error message:  SYSLINUX 3.51 2007-06-10 CBIOS Load Error - boot error.  I tried to recopy the bzimage and bzroot files from 4.5b6 to the flash to return to former files but I still get the same error message.  Cleared CMOS, etc and still get same error message.  I have the P5B-VM-DO MB, 4GB RAM, parity + 11 data drives (12 total HDD).  What do I do now?

 

Last time I ran into this, it ended up being a bad flash drive.

Run checkdsk on the flash drive, make sure it does not have file-system damage.  Make sure you "safely eject" it if you copy the files by moving it to your PC.

 

Joe L.

Link to comment

Thanks for the new release! Two questions:

 

3. An I/O stream via Windows PC freezes when same Windows PC is used to access data on a spundown disk.  This is a Windows problem and can not be fixed by unRAID OS.

 

Does this problem only apply to SMB? Would it help if I installed some NFS client on my Windows PC and used NFS instead of SMB to access unRAID shares?

 

Good question.  I have not tried NFS via Windows to see if Windows opens multiple connections to the same server.

 

In order to keep track of spinup groups and drive spinup status, this state info is maintained in the unRAID driver (because the driver needs to spin up drives based on incoming I/O requests)

 

This makes me wonder: Now that the driver controls spin up/down, could you make it more clever? E.g. it sometimes happens now that when I access a user share, that one disk spins up after the other, and it takes literally a minute or two until all disks are finally spun up. Would it be possible for the unRAID driver to "guess" that this is about to happen and to spin up all needed drives at once, just like the "spin up all drives" button on the HTTP site does?

 

Yes, may be able to do that.  Another way to prevent having to spin up disks for User Share directory listings is to use JoeL's excellant 'cache_dirs' addon.

Link to comment

I just rebootet one server with Beta-12. I could see a file called "go" in directory "/var/log". The contents is:

 

root@Tower:/var/log# cat go
ERROR: Module md_mod does not exist in /proc/modules

 

Is this something I should care about?

 

Thanks

Harald

 

 

Yes this is harmless & expected.

Link to comment

Just wanted to say that while I only watched a couple of 45-minute TV shows last night, I did not experience any of the pausing video issues that having been plaguing me for at least a year.  Before last night, the first video we would watch (whether it was TV or a full-length movie) would always experience the pause within the first 15-30 seconds and at least once more before it finished (usually two or three times).

 

I did not monitor which drives spun up or anything due to the new spinup groups, I just watched as I normally do...the first time without any annoying pauses :]

 

I know that may be too early to call it fixed, but the simple fact that I didn't experience it even once excites me.

 

OK, so-far, so-good.  Amazing how complex it is to get disk spinup/spindown right...  :P

Link to comment

In order to keep track of spinup groups and drive spinup status, this state info is maintained in the unRAID driver (because the driver needs to spin up drives based on incoming I/O requests)

 

This makes me wonder: Now that the driver controls spin up/down, could you make it more clever? E.g. it sometimes happens now that when I access a user share, that one disk spins up after the other, and it takes literally a minute or two until all disks are finally spun up. Would it be possible for the unRAID driver to "guess" that this is about to happen and to spin up all needed drives at once, just like the "spin up all drives" button on the HTTP site does?

 

Since there is the ability to alter the drive groups, I suppose there is a way to segregate user shares to specific drives and set them as part of the drive group.  This could achieve what you want albeit at a slightly more involved set up process.

 

Perhaps later in the game the user share file system could be enhanced to know which drives are involved in a user share thus sending spin up commands to the md drive for all related drives. I'm sure there would be others who would not like this approach. There is already the dir_cache program to help prevent this. In addition, if those doing a write, do not want every drive spinning up just to find free space.

 

Who knows maybe this triggered spin control behavior based on user shares could be achieved by a third party monitor application if the md drive reports when it spins up and spins down drives.

 

One possibility for "guessing" the drives to spin up; if a file in an outer most branch of a user share (in a folder with no child folders) is accessed, and more files in that folder exist on other drives (say, a VIDEO_TS folder from a DVD spanned over many drives), you could then guess that the other files may be needed, and spin up the other disks.  Problem here is that you need the full directory structure from each disk in a user share cached to do this -- and there are many cases that it would "guess wrong".

 

 

Preventing this - having files in one directory span multiple disks - is precisely what split-level feature is designed to prevent!

Link to comment

Thanks for the new release! Two questions:

 

3. An I/O stream via Windows PC freezes when same Windows PC is used to access data on a spundown disk.  This is a Windows problem and can not be fixed by unRAID OS.

 

Does this problem only apply to SMB? Would it help if I installed some NFS client on my Windows PC and used NFS instead of SMB to access unRAID shares?

 

In order to keep track of spinup groups and drive spinup status, this state info is maintained in the unRAID driver (because the driver needs to spin up drives based on incoming I/O requests)

 

This makes me wonder: Now that the driver controls spin up/down, could you make it more clever? E.g. it sometimes happens now that when I access a user share, that one disk spins up after the other, and it takes literally a minute or two until all disks are finally spun up. Would it be possible for the unRAID driver to "guess" that this is about to happen and to spin up all needed drives at once, just like the "spin up all drives" button on the HTTP site does?

 

Funnily enough I've been finding the same issue with the new beta... 

Link to comment

Thanks for the new release! Two questions:

 

3. An I/O stream via Windows PC freezes when same Windows PC is used to access data on a spundown disk.  This is a Windows problem and can not be fixed by unRAID OS.

 

Does this problem only apply to SMB? Would it help if I installed some NFS client on my Windows PC and used NFS instead of SMB to access unRAID shares?

 

In order to keep track of spinup groups and drive spinup status, this state info is maintained in the unRAID driver (because the driver needs to spin up drives based on incoming I/O requests)

 

This makes me wonder: Now that the driver controls spin up/down, could you make it more clever? E.g. it sometimes happens now that when I access a user share, that one disk spins up after the other, and it takes literally a minute or two until all disks are finally spun up. Would it be possible for the unRAID driver to "guess" that this is about to happen and to spin up all needed drives at once, just like the "spin up all drives" button on the HTTP site does?

 

Funnily enough I've been finding the same issue with the new beta... 

 

What is the issue?  Please describe.

Link to comment

Thanks to brainbone and Joe L for advice! 

 

I'm back up on  b12; parity is running now.  Had to reformat the flash drive and start from scratch; I guess something got corrupted when I copied the new bzimage and bzroot directly to the flash drive via my gigabit network rather than putting flash into my PC--I really don't have a clue what happened--I've done this several times and never had an issue until today.  Lost one Pro key when I reformatted but fortunately I had purchased a second from Tom that matches a flash drive GUID and that permitted me to get all 11 data drives started.  I was sure that I had backed-up that key somewhere but cannot find it now; guess I'll research how to get Tom to reissue that key.

 

Thanks again brainbone and Joe.

 

Dan

Link to comment

Thanks for the new release! Two questions:

 

3. An I/O stream via Windows PC freezes when same Windows PC is used to access data on a spundown disk.  This is a Windows problem and can not be fixed by unRAID OS.

 

Does this problem only apply to SMB? Would it help if I installed some NFS client on my Windows PC and used NFS instead of SMB to access unRAID shares?

 

In order to keep track of spinup groups and drive spinup status, this state info is maintained in the unRAID driver (because the driver needs to spin up drives based on incoming I/O requests)

 

This makes me wonder: Now that the driver controls spin up/down, could you make it more clever? E.g. it sometimes happens now that when I access a user share, that one disk spins up after the other, and it takes literally a minute or two until all disks are finally spun up. Would it be possible for the unRAID driver to "guess" that this is about to happen and to spin up all needed drives at once, just like the "spin up all drives" button on the HTTP site does?

 

Funnily enough I've been finding the same issue with the new beta... 

 

What is the issue?  Please describe.

 

My music is stored across multiple drives. It appears that whenever I play one song it will spin up one drive, then another, then another, and then finally play it.

Link to comment

My music is stored across multiple drives. It appears that whenever I play one song it will spin up one drive, then another, then another, and then finally play it.

 

Are the drives that spinup all in the same 'spinup group'?  To check this, identify which drives are spinning up, then click on those drives from the webGui Main page and take note of what is in the "Spinup groups(s)" field for each drive.

 

Are they spinning up serially - that is one after another, or at the same time?

Link to comment

They are all in different groups - haven't touched or played around with it from upgrade yet..  No time!

 

It's spinning them up serially.

 

How is this a different behavior from previous beta?

''

 

It used to only spin up one disk (the one with the file I'm trying to access). Now it's spinning up two or maybe three. Only has happened a couple of times, but certainly different to how it was.

 

Cheers  :)

Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.