unRAID Server Release 6.2 Stable Release Available


limetech

Recommended Posts

  • Replies 443
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

Just wanted to take a moment to give a special thanks to our moderators who have been doing an awesome job in helping support the release of 6.2. You guys are fantastic and thank you for doing what you all do.

 

Thanks to YOU guys at Limetech for a really nice upgrade with 6.2

 

By the way, have you had a chance to take a look at this issue?

https://lime-technology.com/forum/index.php?topic=51878.0

 

REALLY strange that it boots in GUI mode, but simply goes in a reboot loop otherwise.

 

Link to comment

I'm just popping in while in an uber to celebrate life events, but anyone worried about excessive email notifications etc MUST look into Pushbullet.  It is amazing.  And if you happen to not be allowed to bring your phone into your work, but can install a Firefox or Chrome extension, then you can get SMS at work too I frankly judge myself for waiting so long to hop on the train.

 

Link to comment

Just wanted to take a moment to give a special thanks to our moderators who have been doing an awesome job in helping support the release of 6.2. You guys are fantastic and thank you for doing what you all do.

 

Thanks to YOU guys at Limetech for a really nice upgrade with 6.2

 

By the way, have you had a chance to take a look at this issue?

https://lime-technology.com/forum/index.php?topic=51878.0

 

REALLY strange that it boots in GUI mode, but simply goes in a reboot loop otherwise.

 

Have looked at it but can't reproduce just yet. Still a little perplexed on that one but definitely seems like hardware may be a little buggy there.

Link to comment

Smooth upgrade from 6.1.9 to 6.2 Stable.  Quick spot checking shows Plex is working, and my LAMP server in a VM is fine.  Will check the other VMs later (some Linux, some Windows).

 

Started a parity check overnight (I juggled some disks) and that completed in 32953sec ... slightly better than average.  Looking good...

 

Have now added the 2nd parity disk and that build is running.  Watching the Dashboard, the build seems to be using 3 out of 6 cores, easily averaging below 30%, and a max usage below 50%.  Not bad for this (Cortex) somewhat older AMD system.

 

Thanks LimeTech, will report back later, but am not presently expecting any issues.

 

Quick update, Parity2 sync has now completed, 35531sec for 4TB ... again, not bad.

 

Turns out Plex is a little hit-and-miss, so will need to investigate that.  Some stuff works, some stuff is ... behaving strangely.  At a minimum, I know Plex said there was an update pending.  Will work on that as I have time.  Will also check in on the rest of the VMs.  Hopefully tomorrow...

Link to comment

I'm just popping in while in an uber to celebrate life events, but anyone worried about excessive email notifications etc MUST look into Pushbullet.  It is amazing.  And if you happen to not be allowed to bring your phone into your work, but can install a Firefox or Chrome extension, then you can get SMS at work too I frankly judge myself for waiting so long to hop on the train.

 

Agreed. I liked it that much I wanted to attach it to everything so I paid for the non limited service.

Link to comment

 

I originally set up my docker image at

 

/mnt/disk15/docker.img

 

because I have no cache drive and the LT guide advises "The path must be device-specific" and "It is recommended to store the virtual disk on the root of the cache disk or on the root of a data disk if no cache disk is available.'

via http://lime-technology.com/docker-guide/

 

I'm planning to switch my image to the new default system path just to keep everything uniform.

 

Is it still required for the path to be device specific?

 

Would I still be required to use

 

/mnt/disk15/system/docker/docker.img

 

Or can I now use

 

/mnt/user/system/docker/docker.img

 

 

Thanks

 

 

 

 

Link to comment

 

I originally set up my docker image at

 

/mnt/disk15/docker.img

 

because I have no cache drive and the LT guide advises "The path must be device-specific" and "It is recommended to store the virtual disk on the root of the cache disk or on the root of a data disk if no cache disk is available.'

via http://lime-technology.com/docker-guide/

 

I'm planning to switch my image to the new default system path just to keep everything uniform.

 

Is it still required for the path to be device specific?

 

Would I still be required to use

 

/mnt/disk15/system/docker/docker.img

 

Or can I now use

 

/mnt/user/system/docker/docker.img

 

 

Thanks

Either will work just fine.  Technically, using the first is a *hair* faster at access, but you won't notice the difference.
Link to comment

Was there going to be some script/tool to let people know if dual parity would speed or slow down their servers ?

you will never get a speed up from using Dual Parity.    The only question is whether you get a negligible or significant slowdown when running parity checks.

 

OK, was there going to be some tool/script to let people know if their system will noticeably degrade by enabling dual parity ?

 

LT's view is that performance impact will be "minimal". One might interpret that to mean that if you're hardware with single parity (i.e. 6.1.9) performs well then 6.2 should be fine.

 

<<<  snip >>>

 

 

Here is a link to an earlier thread that addresses some of your questions.

 

    http://lime-technology.com/forum/index.php?topic=51036.0

 

One thing to bear in mind is that these tests and experiments were only run on AMD CPU's.  I am not sure what impact dual parity is going to have on older and slower Intel CPU's. 

 

Also, newer slower hardware (after about 2015) may not be impacted as much as older hardware as the CPU's have a new set of extensions that make matrix arithmetic operations much faster.

 

With my Test Bed server, the dual parity non-correcting check time is 10hr 42m and the single parity time would be in the 7hr 52m range.  (I have not checked this with ver 6.2 but I do have a time from one of the later rc versions.)  I have not really checked the direct-write-to-array speeds but I would suspect that they will be about 40% slower.  (I would expect that the Sempron in my Media server would really be impacted (close to double for the parity checking time) if I were to go to dual parity on it.  As you might surmise, I have no intention of going to dual parity on that server.  In fact, I will probably move the parity2 disk to a data disk on the Test Bed when I need more storage space!)

 

40% is a decent hit on performance.  I'm running an i3-2100.  When I have time I'll have to compare results with/without dual.

Link to comment

I originally set up my docker image at

 

/mnt/disk15/docker.img

 

because I have no cache drive and the LT guide advises "The path must be device-specific" and "It is recommended to store the virtual disk on the root of the cache disk or on the root of a data disk if no cache disk is available.'

via http://lime-technology.com/docker-guide/

 

I'm planning to switch my image to the new default system path just to keep everything uniform.

 

Is it still required for the path to be device specific?

 

Would I still be required to use

 

/mnt/disk15/system/docker/docker.img

 

Or can I now use

 

/mnt/user/system/docker/docker.img

Either will work just fine.  Technically, using the first is a *hair* faster at access, but you won't notice the difference.

 

But your original setting at /mnt/disk15/docker.img would work slightly faster yet, "on the root of a data disk".  And there would be less disruption.

 

Squid, would it be correct to say that "unless it is located on an unassigned drive, you don't need to change anything"?

Link to comment

I originally set up my docker image at

 

/mnt/disk15/docker.img

 

because I have no cache drive and the LT guide advises "The path must be device-specific" and "It is recommended to store the virtual disk on the root of the cache disk or on the root of a data disk if no cache disk is available.'

via http://lime-technology.com/docker-guide/

 

I'm planning to switch my image to the new default system path just to keep everything uniform.

 

Is it still required for the path to be device specific?

 

Would I still be required to use

 

/mnt/disk15/system/docker/docker.img

 

Or can I now use

 

/mnt/user/system/docker/docker.img

Either will work just fine.  Technically, using the first is a *hair* faster at access, but you won't notice the difference.

 

But your original setting at /mnt/disk15/docker.img would work slightly faster yet, "on the root of a data disk".  And there would be less disruption.

 

Squid, would it be correct to say that "unless it is located on an unassigned drive, you don't need to change anything"?

Yeah, there is no reason to change anything at all as long as its not on an unassigned drive (which works for some, doesn't work for most people)

 

If you're not going to use LT's default locations for appdata (and once again no real need to), the only thing you should change is the Default appdata storage location to match your appdata location.  Not doing this will not affect any running apps, or any previously installed apps installed through CA's Previous Apps section, but on any new apps getting added the /config mapping may be incorrect that unRaid tries to fill out.

 

 

The only real caveat with this is that you have to manually type the path if its NOT within /mnt/user (on both the docker image location and the appdata location)

Link to comment

 

If you're not going to use LT's default locations for appdata (and once again no real need to), the only thing you should change is the Default appdata storage location to match your appdata location.  Not doing this will not affect any running apps, or any previously installed apps installed through CA's Previous Apps section, but on any new apps getting added the /config mapping may be incorrect that unRaid tries to fill out.

 

 

The only real caveat with this is that you have to manually type the path if its NOT within /mnt/user (on both the docker image location and the appdata location)

 

 

Way back in unraid 5 I made a share called system to store all my plugin and shared configs for stuff over the network. I ended up changing that to appdata when I saw the posts in the 6.2 betas about that being a new default share to avoid any conflicts. So it looks like I'm good on that part. I'll just leave the docker image as is then. With the newish feature of CA being able to back up appdata and the new prefer cache mode I'm more inclined to add a cache drive and move this stuff to it.

 

Thanks again guys

Link to comment

- Unlike 6.1.9, the Docker system in 6.2 no longer supports the docker.img file to be located on a disk mounted with the Unassigned Devices plugin.  You must locate it either on the Cache drive or on the array. 

 

Even if this was never officially supported, this regression is REALLY sad.

 

My cache drive is a HDD and I want it to spun down in case of no activity. Obviously having docker ran from there will prevent the cache drive to spun down. For performance reasons I have a smaller, but more than enough sized SSD installed as an "appdrive" mounted with Unassigned Devices and it worked perfectly with v6.1.9. I had better performance and less power consumption.

 

Now I have to install docker on my cache drive and this will result:

- lower performance

- higher power consumption

- cluttered cache drive with docker stuff

This makes me not so much happy...

 

...or else, I can spend a lot of money to buy a SSD large enough to house cache and docker on what disk, but this would be money to thrown away...

Link to comment

- Unlike 6.1.9, the Docker system in 6.2 no longer supports the docker.img file to be located on a disk mounted with the Unassigned Devices plugin.  You must locate it either on the Cache drive or on the array. 

 

Even if this was never officially supported, this regression is REALLY sad.

 

My cache drive is a HDD and I want it to spun down in case of no activity. Obviously having docker ran from there will prevent the cache drive to spun down. For performance reasons I have a smaller, but more than enough sized SSD installed as an "appdrive" mounted with Unassigned Devices and it worked perfectly with v6.1.9. I had better performance and less power consumption.

 

Now I have to install docker on my cache drive and this will result:

- lower performance

- higher power consumption

- cluttered cache drive with docker stuff

This makes me not so much happy...

 

...or else, I can spend a lot of money to buy a SSD large enough to house cache and docker on what disk, but this would be money to thrown away...

It still works for some people.

 

Sent from my SM-T560NU using Tapatalk

 

 

Link to comment

- Unlike 6.1.9, the Docker system in 6.2 no longer supports the docker.img file to be located on a disk mounted with the Unassigned Devices plugin.  You must locate it either on the Cache drive or on the array. 

 

Even if this was never officially supported, this regression is REALLY sad.

 

My cache drive is a HDD and I want it to spun down in case of no activity. Obviously having docker ran from there will prevent the cache drive to spun down. For performance reasons I have a smaller, but more than enough sized SSD installed as an "appdrive" mounted with Unassigned Devices and it worked perfectly with v6.1.9. I had better performance and less power consumption.

 

Now I have to install docker on my cache drive and this will result:

- lower performance

- higher power consumption

- cluttered cache drive with docker stuff

This makes me not so much happy...

 

...or else, I can spend a lot of money to buy a SSD large enough to house cache and docker on what disk, but this would be money to thrown away...

It still works for some people.

 

Sent from my SM-T560NU using Tapatalk

I'm going to try to symlink a share on my SSD (soon to be my cache drive) to an HDD mounted external.  Since I have been unable to get Unassigned Devices to mount to a location I designate that isn't beneath /mnt/disks - I will have to do it manually.  Then when writing to the cache drive and that share it will write to the HDD.  Just a theory now but unless I recieve negative feed back what I am going to try.
Link to comment

- Unlike 6.1.9, the Docker system in 6.2 no longer supports the docker.img file to be located on a disk mounted with the Unassigned Devices plugin.  You must locate it either on the Cache drive or on the array. 

 

Even if this was never officially supported, this regression is REALLY sad.

 

My cache drive is a HDD and I want it to spun down in case of no activity. Obviously having docker ran from there will prevent the cache drive to spun down. For performance reasons I have a smaller, but more than enough sized SSD installed as an "appdrive" mounted with Unassigned Devices and it worked perfectly with v6.1.9. I had better performance and less power consumption.

 

Now I have to install docker on my cache drive and this will result:

- lower performance

- higher power consumption

- cluttered cache drive with docker stuff

This makes me not so much happy...

 

...or else, I can spend a lot of money to buy a SSD large enough to house cache and docker on what disk, but this would be money to thrown away...

Agreed.  I've been using this setup since Docker was introduced and have been really happy with it.  I'm glad I decided to hold off on upgrading, though.  I asked if it would be OK to upgrade 10 pages or so back and seemingly got some bad advice.

 

Kind of disappointed I need to either add a cache drive I don't want, or leave an array disk spinning 24/7 to use docker now.  Not terribly excited with either option.

 

Edit: It sounds like it was never fully-supported, but it was widely-suggested.  There were a lot of threads when Docker was launched from those of us without cache drives asking what we should do, and Unassigned Devices was almost always suggested given the performance and wear impact of putting the image on the array.

 

Is it possible to simply assign my "Unassigned Devices/Docker" SSD as a cache drive?  Then I think it's possible to go to every User share and disabled Cache drive use, right?  Kind of like a cache drive without any caching?

Link to comment

Is it possible to simply assign my "Unassigned Devices/Docker" SSD as a cache drive?  Then I think it's possible to go to every User share and disabled Cache drive use, right?  Kind of like a cache drive without any caching?

 

You do not have to set any shares to use the cache drive if you don't want to. Other than perhaps your VM share/folder as it would seem.

Link to comment

Is it possible to simply assign my "Unassigned Devices/Docker" SSD as a cache drive?  Then I think it's possible to go to every User share and disabled Cache drive use, right?  Kind of like a cache drive without any caching?

 

You do not have to set any shares to use the cache drive if you don't want to. Other than perhaps your VM share/folder as it would seem.

Neat, thanks.  Sounds like that's the best option for me, then.  I can get docker.img to a supported location, keep using my SSD, and still be able to write all data directly to the protected array without it hitting the cache drive first.

 

Just have to update all my paths.  Shouldn't be too bad, I hope.

Link to comment

Hi everybody,

 

I want to update from unRAID basic 6.1.9 to 6.2, but hitting the "Check for updates" button on the plugin give me "No update" for all my plugins (Preclear disks, Dynamix WebGui and unRAID server OS).

Anybody knows why? I know That I can upgrade using the USB key connected to my computer, but I should be able to do it from the WebGui...

Thanks for the help!

 

 

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.