Talked to a Synology guy today...

[oRBIT]

A few interesting things he mentioned, if anyone's interested...

1) He thought DSM 7.2 final should be out within a month or so.
2) As far as I understood, more budgetfriendly/homeconsumer Synology branded-harddrives should be released very shortly.
3) He thought the NVMe Synology-branded-drives-only-for-storagepools-limitation was going to be removed. They obviously got quite a few unhappy faces for the current implementation.
4) Wireless Synology branded surveillance-cameras are very unlikely to be released due to security-concerns.
5) Synology Chat would soon get videosupport

 

[Telos]

Interesting stuff. Thanks for posting.

 

[Perra]

That would be grand!
Would love saving a drive bay as i run a 2.5" 240gb crucial ssd for my dockers.

 

[Telos]

i run a 2.5" 240gb crucial ssd for my dockers.

You do know that has near zero effect...

 

[Perra]

Hi.
Yeah i know.
Its just to decrease the wake up time of the dockers when they awake from hibernation to a minimum.

 

[Telos]

Its just to decrease the wake up time of the dockers when they awake from hibernation to a minimum.

Then you know that all Synology drives hibernate or sleep together. If you need SSD performance, all drives should be SSD. Segregating packages has no effect. Unsure why your Docker containers are "hibernating". I'll defer to your expertise.

 

[Jan Janowski]

It would be nice if 720+ NVME's could be used as storage.... That certainly would have helped the recent HD to SSD SHR Upgrade be resolved FAR EASIER than the convoluted approach I had to take... Where HB was found not to 'see' prior HB created Backup as a Restore!
By the way, Support had never heard of this.... I suggested he try it...
R/W Cache doesn't provide the expected benefit anyway........... So might as well make it available to do something good.....

 

[itsjasper]

Use the unofficial script and they can be...

It has been running fine on my 720+ for a few months now.

 

[Jan Janowski]

Script run as admin from task Scheduler, run NOW?

I'm Nosy..... ???? clicked on unofficial script ---- Not Found...

 

[dimfil]

Script run as admin from task Scheduler, run NOW?

I'm Nosy..... ???? clicked on unofficial script ---- Not Found...

GitHub - 007revad/Synology_HDD_db: Add your HDD, SSD and NVMe drives to your Synology's compatible drive database and a lot more

Add your HDD, SSD and NVMe drives to your Synology's compatible drive database and a lot more - 007revad/Synology_HDD_db

github.com

 

[mikey_s]

Interesting, if they remove the lock on the M2 drives and such I'll move off a QNAP 873A for a DS1812+ unit. I did try a 1821+ recently, but the drive caddies were faulty and Amazon would only refund. They're now more expensive, so I'm didn't purchase another for the moment.

Waiting to to see DSM 7.2 released and how drive compatibility goes. Ideal world would be my 873A with DSM

 

[oRBIT]

Use the unofficial script and they can be...

It has been running fine on my 720+ for a few months now.

How safe is this? If Synology releases a new DSM version and breaks something...

 

[Deleted member 5784]

How safe is this? If Synology releases a new DSM version and breaks something...

Pretty safe. It's just a bash script, and as such anyone can view it and follow what it does. There's nothing in there that is 'hidden' or unknown. I've had a cursory look through it and it all looks reasonable.

The script makes a backup of the existing synology HDD database, so nothing is lost. At worst, you could issue commands or run another script that simply puts the old db back if you had to.

The script then adds entry(ies) for the HDDs that you are running to the whitelist db, so they dont trigger DSM warnings.

The script also attempts to disable auto updating of the DB by DSM. It warns that the modified db will almost certainly get overwritten during a DSM update, so the script should be re-run after such.

Its all about as 'safe' as can reasonably be expected; the realQs to ask are 'what could this mess up?' and 'can I recover this if it does go wrong' and the answers imo are 'not much' and 'yes, trivially'.

 

[itsjasper]

...and having a tested backup strategy mitigates any risk.

 

[ctrlaltdelete]

) He thought the NVMe Synology-branded-drives-only-for-storagepools-limitation was going to be removed. They obviously got quite a few unhappy faces for the current implementation.

But only for the newer models DS923+, DS1522+and other new? Not for DS920+?

 

[Jan Janowski]

Or 720+?

 

[oRBIT]

But only for the newer models DS923+, DS1522+and other new? Not for DS920+?

I am not sure but I think I read somewhere that there's some kind of hardware limitation, that it is only for newer diskstations.. Someone correct me if I'm wrong..

 

[dimfil]

I am not sure but I think I read somewhere that there's some kind of hardware limitation, that it is only for newer diskstations.. Someone correct me if I'm wrong..

I have heard of this information too, referring to nvme limitations. If I remember correctly this info was on a video from NASCompares or SpaceRex channel.
On the other hand, this scripts reports that can succesfully enable M2 volume creation on 920+ with DSM 7.2 installed, along with other in theory unsupported models.
So, what could be the real reason?

 

[ctrlaltdelete]

Ok, I‘m using this one:

GitHub - 007revad/Synology_HDD_db: Add your HDD, SSD and NVMe drives to your Synology's compatible drive database and a lot more

Add your HDD, SSD and NVMe drives to your Synology's compatible drive database and a lot more - 007revad/Synology_HDD_db

github.com

 

[dimfil]

Ok, I‘m using this one:

GitHub - 007revad/Synology_HDD_db: Add your HDD, SSD and NVMe drives to your Synology's compatible drive database and a lot more

Add your HDD, SSD and NVMe drives to your Synology's compatible drive database and a lot more - 007revad/Synology_HDD_db

github.com

I use that too because I also want to suspend the unsupported memory alert. Same creator, as the one I posted earlier.