unRAID Server Release 6.0-beta14b-x86_64 Available

[jonp]

Question, also maybe not the best thread and could get buried in here, but someone is bound to look at it and confirm/deny.

 

HDD's seem to spin up when they shouldn't when browsing the Web GUI.

 

Explanation:

 

I head to the main page and see all drives spun down except for one disk that I use for a data storage location in a KVM VM with a QCOW2 image (as expected).

I browse to the docker tab (3 are running, all good here).

Browse over to the KVM tab to check on my one Win7 VM that is running, it takes a couple of moments to come up (could of been what triggered the drives?), all is good and running.

I RDP into the Win 7 machine, all looks good, nothing really going on, don't move/do anything, just verify UTorrent is running/doing its thing.

I go back to the Main Web GUI page (this is all in a matter of like a minute) and 3 additional drives are no spun up, 1 parity, and 2 array data drives!

 

I didn't actually access or browse to any files, the VM was running the whole time, VM is on the cache drive... Not sure why this behavior/action would spin up any drives, but it certainly seemed to.

I looked quickly at the system log, but don't see anything useful in regards to the disks spinning up... All the info in there is from hours prior.

Could your windows VM have been indexing the files on the array?  Are you running Plex or Kodi on another computer and they were rescanning the array?

 

I think that the only real way to diagnose if unRaid is spinning up drives on its own is to turn off everything else that has the potential to access the drives (ie - every other computer / vm on the network) and see what happens.

Bingo.

[bubbaQ]

Device spinning status is now maintained internally and the actual devices are no longer interrogated to get their spinning state.  This means that if you manually use

hdparm -y

to spin down devices, or use a 3rd party plugin that does so, the webGui will likely get out of sync with the actual device state.  So don't do that.

 

I'm OK with going that route, but there are too many things (like a smartctl query) that can spin up a drive and no telling if some plugin or other app might do a spin-up/down via an IOCTL without the user being aware of it.

 

So please put a button on the UI to "Check spin status of drive(s)" to "resync" the UI with the actual spinstate.

[jonp]

Device spinning status is now maintained internally and the actual devices are no longer interrogated to get their spinning state.  This means that if you manually use

hdparm -y

to spin down devices, or use a 3rd party plugin that does so, the webGui will likely get out of sync with the actual device state.  So don't do that.

 

I'm OK with going that route, but there are too many things (like a smartctl query) that can spin up a drive and no telling if some plugin or other app might do a spin-up/down via an IOCTL without the user being aware of it.

 

So please put a button on the UI to "Check spin status of drive(s)" to "resync" the UI with the actual spinstate.

This applies to spin down only, not spin up.

 

Edit:  need to verify with tom, but that is my understanding.

[bungee91]

Question, also maybe not the best thread and could get buried in here, but someone is bound to look at it and confirm/deny.

 

HDD's seem to spin up when they shouldn't when browsing the Web GUI.

 

Explanation:

 

I head to the main page and see all drives spun down except for one disk that I use for a data storage location in a KVM VM with a QCOW2 image (as expected).

I browse to the docker tab (3 are running, all good here).

Browse over to the KVM tab to check on my one Win7 VM that is running, it takes a couple of moments to come up (could of been what triggered the drives?), all is good and running.

I RDP into the Win 7 machine, all looks good, nothing really going on, don't move/do anything, just verify UTorrent is running/doing its thing.

I go back to the Main Web GUI page (this is all in a matter of like a minute) and 3 additional drives are no spun up, 1 parity, and 2 array data drives!

 

I didn't actually access or browse to any files, the VM was running the whole time, VM is on the cache drive... Not sure why this behavior/action would spin up any drives, but it certainly seemed to.

I looked quickly at the system log, but don't see anything useful in regards to the disks spinning up... All the info in there is from hours prior.

Could your windows VM have been indexing the files on the array?  Are you running Plex or Kodi on another computer and they were rescanning the array?

 

I think that the only real way to diagnose if unRaid is spinning up drives on its own is to turn off everything else that has the potential to access the drives (ie - every other computer / vm on the network) and see what happens.

Bingo.

 

Nothing else going on at that moment that I know of. No clients on or accessing the array at that moment, just me clicking on a page or two checking if all was okay.

IDK, whatever, not going to lose sleep over it. Will try similar things in the future and see if the same or similar things happen.

[NAS]

Am I being blind, where are the change release notes for 6.0-beta14b-x86_64?

[olympia]

Am I being blind, where are the change release notes for 6.0-beta14b-x86_64?

 

The same place as for all releases:

http://dnld.lime-technology.com/beta/unRAIDServer-6.0-beta14b-x86_64.txt

[NAS]

Ta (hungover blindness)

 

FYI

 

Its also in the webgui but not in the OP of the thread like every other release ever?. Also it seems the wiki version is no longer maintained beyond v6b12 which is a shame as it the single most definitive source of change information

 

It is all good, its just not as slick as it could, or has been.

[sacretagent]

Can Limetech please explain me if i can upgrade my server where i used fdisk to partition 1 big part of my cache disk in btrfs and 1 very  small part in raw to be used for swap file ?

i spend 5 days on my other server to retrieve my complete tv database in plex...

this server had 6000 movies in plex... which i would hate to rescan all

 

so how do i go about it ?

 

With -beta14 or higher we don't mess with the partition structure of a single cache disk if there already exists a mountable partition 1, so I think you should be good.  To be safe you could use 'dd' command to save your current MBR record to a file:

 

dd if=/dev/sdX of=/boot/mbr.backup count=1

 

(Replace 'sdX' with device name of your specific cache device.)

 

After you upgrade and start array, if your cache device comes up 'unmountable' then do not click Format - instead send me email: [email protected].  But this shouldn't happen

 

Thanks guys,

 

I took the jump today and upgraded both systems to 14B without issues

the one with the raw swap file didn't have any problemsto find the partitions

everything is up and running

the gui seems MUCH snappier in this version

overall the machines seems faster too

 

will need to do some testing for that

[olympia]

Ta (hungover blindness)

 

FYI

 

Its also in the webgui but not in the OP of the thread like every other release ever?. Also it seems the wiki version is no longer maintained beyond v6b12 which is a shame as it the single most definitive source of change information

 

It is all good, its just not as slick as it could, or has been.

 

Why, there is a direct link from the download page... How could this be more slick?

[NAS]

It excludes the md5 sum of all but the very newest versions and the change log of everything before Nov 2013. It also excludes the dates of release of all but a couple of versions.

 

It is nice it is a flat txt file but content wise it is lesser than the the wiki which has been maintained continually since 2009.

[jonp]

It excludes the md5 sum of all but the very newest versions and the change log of everything before Nov 2013. It also excludes the dates of release of all but a couple of versions.

 

It is nice it is a flat txt file but content wise it is lesser than the the wiki which has been maintained continually since 2009.

We also have the notes in the webgui itself in multiple places. If someone wants to maintain them in the wiki too, that's great, but we are trying to reduce the amount of effort it takes to generate releases so we can generate them more frequently.

[NAS]

That is completely fine and in many respects I like the new way better. Certainly it being official is a win in all respects.

 

However needs all historical records ported over and dates added to the release notes themselves then all others can be deprecated.

[archedraft]

I have noticed over the last few days that I have been getting email notifications very sporadically. I have been doing some internal testing and might know what is going on but it would be interesting to know if anyone else is having the same problems.

 

Theory: Email notifications are directly tied to browser notifications and both must be enabled in order to get email notifications.

 

Detail: I only get email notifications if the browser Notification entity is also enabled. Also I have noticed that I do not get sent email notifications until I log into the unRAID web gui and then after a few seconds the browser notifications gets triggered with (Notice [unRAID] - array health report [PASS]) and then it sends me an email. As a test I turned off browser Array status notifications and have not received an email in the last 3 days.

 

I am assuming this is not normal behavior?

 

UPDATE:

I turned browser notifications back on yesterday and I finally got an email last night.

[Squid]

UPDATE:

I turned browser notifications back on yesterday and I finally got an email last night.

If it works, it works.  In my case, I still receive emails with browser settings not checked. (Although they aren't populating into the archive).  But, still not working after a reboot until the GUI is loaded

[archedraft]

UPDATE:

I turned browser notifications back on yesterday and I finally got an email last night.

If it works, it works.  In my case, I still receive emails with browser settings not checked. (Although they aren't populating into the archive).  But, still not working after a reboot until the GUI is loaded

Completely disagree about if it works, it works (why even give the choice to choose email and/or browser notifications, if the only options are browser only or browser AND email...) Anyways, just reporting back with what I consider strange behavior.

[archedraft]

I may have found another bug?

 

My syslog has not been recording activity since 3/1/2015... It's be on 24/7 since 2/27/2014.

 

Syslog attached:

syslog.zip

[Squid]

UPDATE:

I turned browser notifications back on yesterday and I finally got an email last night.

If it works, it works.  In my case, I still receive emails with browser settings not checked. (Although they aren't populating into the archive).  But, still not working after a reboot until the GUI is loaded

Completely disagree about if it works, it works (why even give the choice to choose email and/or browser notifications, if the only options are browser only or browser AND email...) Anyways, just reporting back with what I consider strange behavior.

Like I was saying, email ONLY works fine for me

[StevenD]

Would you care to share why this was done?  It's incredibly annoying.

 

 

 

Some notes on this release:

• The 'mover' will now completely skip moving files off the cache disk/pool for shares marked "cache-only".  However it will move files off the cache disk/pool for shares not explicitly configured "cache-only" in the share's Share Settings page; even for shares that only exist on the cache!  This is different behavior from previous releases!

[olympia]

Would you care to share why this was done?  It's incredibly annoying.

 

 

 

Some notes on this release:

• The 'mover' will now completely skip moving files off the cache disk/pool for shares marked "cache-only".  However it will move files off the cache disk/pool for shares not explicitly configured "cache-only" in the share's Share Settings page; even for shares that only exist on the cache!  This is different behavior from previous releases!

 

It still doesn't move folders with foldername begins with a dot (".example") though. Maybe reduce your annoyance

[prostuff1]

Would you care to share why this was done?  It's incredibly annoying.

 

 

 

Some notes on this release:

• The 'mover' will now completely skip moving files off the cache disk/pool for shares marked "cache-only".  However it will move files off the cache disk/pool for shares not explicitly configured "cache-only" in the share's Share Settings page; even for shares that only exist on the cache!  This is different behavior from previous releases!

It may be annoying to you but it is the way it should have been from the beginning IMO.

[HellDiverUK]

Cache drive should be a cache drive.  If you want to start cramming stuff on there, or running apps and Docker and god knows what else, stick in another drive and mount it using SNAP and use it for all your junk.  That's the way I run it, and I've NO issues with stuff getting stuck or going missing off cache.

[trurl]

Cache drive should be a cache drive.  If you want to start cramming stuff on there, or running apps and Docker and god knows what else, stick in another drive and mount it using SNAP and use it for all your junk.  That's the way I run it, and I've NO issues with stuff getting stuck or going missing off cache.

Or just put it in a cache-only share, and then unRAID will manage it for you without the need to resort to yet another drive that you basically have to manage yourself. Could be very important if you don't have a lot of ports or bays in your server.

 

I don't even use my cache drive for caching. To each their own I guess.

 

[barakthecat]

Would you care to share why this was done?  It's incredibly annoying.

 

 

 

Some notes on this release:

• The 'mover' will now completely skip moving files off the cache disk/pool for shares marked "cache-only".  However it will move files off the cache disk/pool for shares not explicitly configured "cache-only" in the share's Share Settings page; even for shares that only exist on the cache!  This is different behavior from previous releases!

 

This one just bit me the other day as we are no longer able to have the docker.img reside on a user share. Adding it to a cache the way listed in the directions essentially creates a share on the cache drive that isn't marked as cache only, resulting in the mover moving the docker.img to disk1, which will causer docker to fail upon reboot.

[trurl]

Would you care to share why this was done?  It's incredibly annoying.

 

 

 

Some notes on this release:

• The 'mover' will now completely skip moving files off the cache disk/pool for shares marked "cache-only".  However it will move files off the cache disk/pool for shares not explicitly configured "cache-only" in the share's Share Settings page; even for shares that only exist on the cache!  This is different behavior from previous releases!

 

This one just bit me the other day as we are no longer able to have the docker.img reside on a user share. Adding it to a cache the way listed in the directions essentially creates a share on the cache drive that isn't marked as cache only, resulting in the mover moving the docker.img to disk1, which will causer docker to fail upon reboot.

Simpler to just put docker.img at /mnt/cache/docker.img then it won't be in a share at all and won't get moved.

[prostuff1]

This one just bit me the other day as we are no longer able to have the docker.img reside on a user share. Adding it to a cache the way listed in the directions essentially creates a share on the cache drive that isn't marked as cache only, resulting in the mover moving the docker.img to disk1, which will causer docker to fail upon reboot.

Sure you can... you just have to set that use share as a cache-only share