Unraid OS version 6.9.2 available

[Zonediver]

8 hours ago, PeteAron said:

As a data point. My primary server is now 10 years old, and I continue to use the same flash drive.  Perhaps I should prophylactically upgrade?

 

Not really - my Stick is from Nov. 2012 and still working 👍

[Frank1940]

10 hours ago, PeteAron said:

As a data point. My primary server is now 10 years old, and I continue to use the same flash drive.  Perhaps I should prophylactically upgrade?

 

What I would do is to make sure that you always have a current backup of the contents of that flash drive on a separate PC.  

              Main  >>  Boot Device  >>>  click on 'Flash' under "Device"   >>  Flash Device Settings   >> click on 'Backup' button

While CA Backup will create a backup of the boot drive, it is on the array and you can't get at it without creating a working boot drive for your server--- a catch 22 situation.

 

Next, I would purchase a new USB2 full-size flash drive smaller than 32GB that bears the name of a manufacturer that actually manufactures memory products.  (It appears that heat is the thing that tends to kill flash drives.  USB2 drives run cooler and being full size will prompt better heat dissipation.  Speed is not a factor for the way Unraid uses the boot drive.  Unraid reads about 500MB when the server boots and then ignores the drive until it writes a single file at shutdown.)  That way you will have a replacement drive on hand if (and when) the present drive fails.  (The reason I suggest doing this, while your present drive is functional, is that it is actually difficult now to find a flash drive that will meet all of these criteria!)

[ChatNoir]

3 minutes ago, Frank1940 said:

While CA Backup will create a backup of the boot drive, it is on the array and you can't get at it without creating a working boot drive for your server--- a catch 22 situation.

It does not have to be. My backups are done over the network (appdata + flash drive).

You just have to add the path to Unassigned Devices.

[Frank1940]

46 minutes ago, ChatNoir said:

It does not have to be. My backups are done over the network (appdata + flash drive).

You just have to add the path to Unassigned Devices.

 

Under the settings for CA Backup/Restore, I now find this:

 

The Unraid.net plugin is still in Beta and there is no formal support thread for it yet...

 

However, it appears that CA Backup still does work for the USB drive on 6.9.2 since it is only 'Deprecated' at this point.  With a external mounted drive requires that you have a separate computer/server running at the time when CA backup is doing its thing.  Perhaps, not an issue for those of us who have two servers but it could be an issue for many other folks.

[Squid]

It's deprecated, but not going to be removed.

 

The story is that appdata backup introduced automated flash backups prior to any method within the GUI

The the GUI permitted manual backups. Since it wasn't automated, I didn't deprecate the backup script

Now Unraid.net introduces automated on the fly backups.  It's ideal, works great, and that part of Unraid.net is bug-free.  You do not need need to use the remote access features of Unraid.net in order to take advantage of the flash backup features.

 

 

[ljm42]

6 hours ago, Frank1940 said:

The Unraid.net plugin is still in Beta and there is no formal support thread for it yet...

 

Feel free to send folks to the announcement thread for support:

 

[JustOverride]

19 hours ago, XiuzSu said:

• Updated 6.9.1 -> 6.9.2 without issues....except

"

WARNINGS FOUNDSUGGESTED FIX

Share Public Programs Share set to prefer a cache pool, but will not move Due to a current issue in Unraid 6.9.2, shares with spaces in them will never get moved to the cache pool. Advised to rename the share without using a space"

 

 

Is this a fix that will be coming to unraid, or should I just change the name of the share?
 

[Squid]

1 hour ago, XiuzSu said:

 

 

Is this a fix that will be coming to unraid, or should I just change the name of the share?
 

Next release

[jortan]

On 4/16/2021 at 10:27 AM, PeteAron said:

As a data point. My primary server is now 10 years old, and I continue to use the same flash drive.  Perhaps I should prophylactically upgrade?

 

I just replaced my original USB drive from 2008, the only reason I did is because my 1GB drive needed manual intervention each upgrade due to space issues (need to remove the previous backup)

 

If nothing else it may be worth having a quality spare on-hand.  The Kingston DTSE9 is well regarded (not the G2 version).  

[Zonediver]

4 hours ago, jortan said:

The Kingston DTSE9 is well regarded (not the G2 version).  

 

The stick is from 2011 and almost no longer available.

A "replacement type" would be desirable...

[jortan]

45 minutes ago, Zonediver said:

from 2011 and almost no longer available.

A "replacement type" would be desirable...

 

The DTSE9 model is still available though?

 

Few USB 2.0 drive models would still be manufactured these days.  For various reasons USB 3.0 thumb drives seem to be less reliable on average, which is another reason why you might want to have a few good quality spare USB 2.0 drives. 

[JorgeB]

42 minutes ago, jortan said:

The DTSE9 model is still available though?

It is, only the 32GB model, 16GB and smaller were discontinued.

[dlandon]

For those with the rpcbind log spamming issue, apply this fix.  Add the following line to your go file:

sed -i s"#rpcbind -l#rpcbind#" /etc/rc.d/rc.rpc

and reboot your server.

 

If you want to apply the fix while the server is running, do the following:

• Unmount all your NFS remote mounts
• Execute the following commands.

sed -i s"#rpcbind -l#rpcbind#" /etc/rc.d/rc.rpc
/etc/rc.d/rc.rpc restart
/etc/rc.d/rc.nfsd restart

• Mount all your NFS remote mounts.

This will be fixed in the next release.

[tomjrob]

Upgraded from 6.8.3 to 6.9.2 a few days ago. Upgrade went smoothly and all Dockers and VM's are running great.

Only issue was the cache prefer setting not working on a share with a space. renamed shared to remove space and all working.

 

Thanks to the entire team for the great work.

 

Next step is to try multiple cache pools.

[jbartlett]

On 4/15/2021 at 3:56 PM, ken-ji said:

Well I had a parity check run then and the speeds got capped to the slow 60MBs so its not the DiskSpeed-Docker's fault I think.

My DiskSpeed app uses the dd utility to read the drive for 15 seconds for each drive on the controller in succession, then the same command against each drive all at once. To get slower speeds during single-drive reads vs multiple drive concurrent reads is weird. I'd have to say that it's not my app but my app is showing the issue at hand.

Edited April 20, 2021 by jbartlett

[visionmaster]

I tried updating to 6.9.1, 2 weeks ago from 6.8.3 which has been stable for years.  I had the Seagate drive issue after the drives spin down and then spin back up, I start getting read errors on 2 versions of my Seagate drives (ST8000VN004 and ST8000VN0022).  Once reverting, no issues and stable again.  I just tried to upgrade to 6.9.2 and immediately back to same 2 drives and spin up read errors, so I back to stable on 6.8.3.  Hopefully fixed on next update.  Those are the only type of Seagate drives affected on my system.  My 4TB Seagates work fine.  My drive controllers are Supermicro (MV88SX6081 8-port SATA II PCI-X Controller and MV64460/64461/64462 System Controller, Revision B).

 

[optiman]

16 minutes ago, visionmaster said:

I tried updating to 6.9.1, 2 weeks ago from 6.8.3 which has been stable for years.  I had the Seagate drive issue after the drives spin down and then spin back up, I start getting read errors on 2 versions of my Seagate drives (ST8000VN004 and ST8000VN0022).  Once reverting, no issues and stable again.  I just tried to upgrade to 6.9.2 and immediately back to same 2 drives and spin up read errors, so I back to stable on 6.8.3.  Hopefully fixed on next update.  Those are the only type of Seagate drives affected on my system.  My 4TB Seagates work fine.  My drive controllers are Supermicro (MV88SX6081 8-port SATA II PCI-X Controller and MV64460/64461/64462 System Controller, Revision B).

 

First, you'll want to read and decide if you want to make the suggested drive fw changes. https://forums.unraid.net/topic/103938-69x-lsi-controllers-ironwolf-disks-summary-fix/

 

Can you confirm which controller you have these two Seagate drives connected to?

[Zonediver]

On 4/21/2021 at 1:34 AM, visionmaster said:

I tried updating to 6.9.1, 2 weeks ago from 6.8.3 which has been stable for years.  I had the Seagate drive issue after the drives spin down and then spin back up, I start getting read errors on 2 versions of my Seagate drives (ST8000VN004 and ST8000VN0022).  Once reverting, no issues and stable again.  I just tried to upgrade to 6.9.2 and immediately back to same 2 drives and spin up read errors, so I back to stable on 6.8.3.  Hopefully fixed on next update.  Those are the only type of Seagate drives affected on my system.  My 4TB Seagates work fine.  My drive controllers are Supermicro (MV88SX6081 8-port SATA II PCI-X Controller and MV64460/64461/64462 System Controller, Revision B).

 

 

FYI: Marvel controllers are "not" recommended for unraid. They have known issues with the firmware

[ken-ji]

On 4/15/2021 at 8:46 PM, ken-ji said:

I'm wondering if anybody with an LSI card using the mpt3sas driver has noticed any speed issues?

I'm using a LSI SAS9206-16E HBA and its dual linked to an expander / enclosure - ARC-4036

I've had this setup for a long while now and I've always gotten the maximum speed out of all my HDDs from it.

But when I upgraded to 6.9.2 this weekend, half of my drives on the HBA started running at 60MBs only compared to the usual ~200MBs

When I reverted back to 6.9.1 the drives all ran at their max speed

 

When I have time, I'll try to upgrade again and see if the problem occurs again

I don't have the all drives benchmark in 6.9.2 which gives really weird results.

^ This is Disk 5 (black is 6.9.2)

Ok. now that I have time to try upgrading again. I did and the problem has gone away.

The one thing I did though beforehand was to finally flash my controller to P40 so maybe that was it.

 

[John_M]

Has anyone else noticed the context menu of the "thumbs up" SMART health icons on the Dashboard not working? The three options all take you to the top of the relevant disk's page, instead of the appropriate section. I thought I'd ask here before posting a bug report, in case it turns out to be a browser issue.

 

 

[KeithAbbott]

28 minutes ago, John_M said:

Has anyone else noticed the context menu of the "thumbs up" SMART health icons on the Dashboard not working? The three options all take you to the top of the relevant disk's page, instead of the appropriate section. I thought I'd ask here before posting a bug report, in case it turns out to be a browser issue.

 

 

Mine is behaving the same way, using Firefox.

[ChatNoir]

I generally do not use that but I confirm that all 3 only bring me to the top of the page.

[Squid]

Works properly on Chrome though. (And also on Firefox / Brave for me)

[ChatNoir]

Oh I forgot to mention, I tested on Chrome and FF. 

[John_M]

57 minutes ago, Squid said:

Works properly on Chrome though. (And also on Firefox / Brave for me)

 

Interesting. I'm using Firefox on macOS. I just tried Chrome and get the same result as I did previously. I'll try clearing the cache and I'll give Windows a try. One thing I notice is that the URL that each of the three menu options links to is the same - https://<private-hash>.unraid.net/Dashboard/Device?name=disk4 where I would expect something along the lines of #attributes, #capabilities or #identity at the end (are they called fragments or anchors, or something?).

 

Edit: I've cleared the caches and it still behaves the same. I've tried it on Firefox and Chrome on a different (Apple silicon) MacBook Pro. I've tried Firefox and Chrome on a real Windows 10 computer and a virtual one. I've tried Firefox on a Linux Mint computer and I've tried Chromium on a Raspberry Pi. They all behave exactly the same. Then I reapeated all tests with a second Unraid server, running 6.9.2 and got eactly the same results.