Models (platforms) running the latest version DSM 7.2-64570 Update 3.

[PeterSuh-Q3]

Thanks to you @007revad for the wonderful script.
On my M-SHELL for TCRP
I applied your Synology enable M2 volume script as Addon.

https://github.com/PeterSuh-Q3/tcrp-addons/blob/main/nvmevolume/src/nvmevolume.sh

Like @wjz304's arpl-i18n, ARPL or TCRP cannot use automatic updates to exist as a service within DSM.
In order to follow your script, it seems that we have no choice but to upgrade the static version.

Among the models supported by M-SHELL for TCRP, I tested all the models you listed.

DS3622xs+ and RS4021xs+ have an issue where the latest version 7.2-64570 cannot be used.
Broadwellink, including these two models, has a peculiarity of not displaying the M.2 storage panel.
The same Broadwellnk platform, but managing nvme differently
DS1621xs+ seems to be an exception. (with libsynonvme.so.1 patch)

DS423+, DS1522+ and DS420+ are not yet supported by my program, but I am considering adding them as support models in the future.

For all other models, 7.2-64570 Update 3 works fine.
This is the model below.
Compatibility of DSM versions seems to be platform dependent rather than model specific.

DS923+ (r1000)
DS1821+ (v1000)
DS1621xs+ (broadwellnk)
DS1019+ (apollolake)
DS918+ (apollolake)
DS920+ (geminilake)
DS720+ (geminilake)

Regarding the redfill XPENOLOGY, I tested a few more platforms for compatibility not yet mentioned.
I have a problem with my test.
The results will be reported again a little later.

DS3617xs (Broadwell)
DVA3221 (Denverton)

[PeterSuh-Q3]

DS3617xs (Broadwell) does not work with any DSM version.

The output of the script shows that the patch was successfully patched.

[PeterSuh-Q3]

It was confirmed that DS3617xs (Broadwell) does not work with DSM 7.1.1-42962 U1, so I rechecked DSM 7.1.1-42962 U1 for DS3622xs+ (Broadwell).

Also, the result of the script shows that the patch was successfully patched.
But it doesn't work.
I'm not sure about my TCRP
I tried it once more with ARPL.

DS3622xs+ does not work with DSM 7.1.1-42962 U1.

[007revad]

Thanks Peter. This feedback is excellent. And it explains some of the issues people have raised when using this script and my syno_hdd_db script with XPENOLOGY.

It will take me a while to digest everything you've mentioned. I'm sure I'll have some questions.

At the moment I looking at your install-nvme-cache.sh script and dtb files.

• You have 50 different models listed in rpext-index.json
• But only 5 models listed in universal.json
• There were 33 models that had a device tree blob the last time I checked DMS 7.2-64570 (but there has been a couple of new models released since then).

I found your repository a few days ago while searching the XPENOLOGY forum while looking for information on what could be causing my Synology_HDD_db script to cause the M.2 storage panel to not be displayed. Instead of finding an answer I was happy to find the dtc binary on your repository. I can now run dtc commands directly in DSM instead of needing a Linux VM.

[PeterSuh-Q3]

One more piece of advice, don't manage separate dtb files for each model like in your repo.
https://github.com/007revad/Synology_HDD_db/tree/main/dtb

dtb files are collected in real time while XPE is installed.
After converting to dts, inject the desired part and regenerate it into dtb again.

XPE has a process of collecting and using dtb existing in /tmpRoot in the junior process when DSM is installed.

Your script looks a bit different than this.
This is because dtb needs to be patched when DSM is already installed.
There's nothing wrong with that.
Just patch and reboot.

[PeterSuh-Q3]

All 50 or more items listed in rpext-index.json are not models, and if you look closely, you can see that several revisions are listed again in one model.
Since the mechanism of TCRP is supposed to be static, it has to be listed like this.
Models are not listed in universal.json
Five bins and libs files to be operated in the nvme-cache addon are defined.
Currently, the models supported by my M SHELL for TCRP are as follows.

I plan to add the three models mentioned above.

I'm glad that my repo helped you in your work.

Currently, the NVMe volume activation script does not work on all 3 platforms below.
Broadwell
broadwellnk
Denverton

The most popular model of XPE is DS3622xs+ (broadwellnk).
Along with the problem that the storage panel is not displayed, users seem to be most interested in this part.

Thank you for your reply.

[PeterSuh-Q3]

Is redpill-dtb-static the one you care about?
I mistook it for nvme-cache.
Redpill-dtb-static is a deprecated addon for handling dtb.
In a more up-to-date way, wjz304 will inform you of an addon that has been improved in arc.
I'll check it out in a minute.

[PeterSuh-Q3]

The latest way to handle dtb is the addon below.

https://github.com/PeterSuh-Q3/tcrp-addons/tree/main/dtbpatch

Some of the scripts of ARC are used to assemble the dts file first.

Activation of M.2 is also included in this.

[007revad]

What is different about readlink compared to DSM's /bin/readlink ?

[PeterSuh-Q3]

As already mentioned above, in Junior state not all packages of DSM are configured yet. readlink is one of them. Since readlink does not yet exist in /tmpRoot/bin, we have no choice but to copy and use it.
XPE has a lot of bins and libs that need to be used like this.

[007revad]

So /tmpRoot is created by the junior process and deleted afterwards?

[PeterSuh-Q3]

Yes, you can see that.
/tmpRoot is a temporary mounted directory in junior state.

[007revad]

Do you know how the DSM decides whether to use model.dtb, model_r1.dtb or model_r2.dtb when there is more than just model.dtb?

[PeterSuh-Q3]

I was curious about this before and asked about it.
fbelavenuto/arpl-addons#11 (comment)

However, I have never actually experienced the existence of mode_r1.dtb or mode_r2.dtb.

Additionally, linuxrc.syno.impl refers to two different hardware revisions of the ds920p. Depends on HW_VERSION and HW_REVISION

HW_VERSION=cat /proc/sys/kernel/syno_hw_version
HW_REVISION=cat /proc/sys/kernel/syno_hw_revision

if [ "xr1" = "x${HW_REVISION}" ] && [ -e /etc.defaults/model_r1.dtb ]; Then
cp -vf /etc.defaults/model_r1.dtb /var/run/model.dtb
else
cp -vf /etc.defaults/model.dtb /var/run/
fi

I had a script like this, but I'm not sure if I need to find model_r1.dtb / model_r2.dtb.

Now the scripts ignore the existence of these two files and handle only model.dtb.

Below is the most representative script for ARC's disks addon.

https://github.com/AuxXxilium/arc-addons/blob/main/disks/install.sh

There has never been an issue with not handling model_r1.dtb / model_r2.dtb in the current XPENOLOGY model.

[007revad]

Thank you. This is very helpful.

Out of the 113 Synology NAS models that are supported by DSM 7.2 only 2 have multiple model.dtb files:

The DS920+ (as you mentioned) has:

1. model.dtb
2. model_r1.dtb
3. model_r2.dtb

The DS720+ has:

1. model.dtb
2. model_r1.dtb

I've only compared the ones from the DS720+
007revad/Synology_HDD_db@678389f

[007revad]

If cat /proc/sys/kernel/syno_hw_revision returns rN then I can assume it's a real Synology NAS and I will need to edit model_rN.dtb instead of model.dtb (if it a devicetree model and has a PCIe slot).

I just realised there are 3 copies of model.dtb in DSM:

1. /etc.defaults/model.dtb
2. /etc/model.dtb
3. /var/run/model.dtb

The model.dtb in /var/run has power_limit = "14.85,9.075"; but the other 2 don't.

My script only edits the model.dtb in /etc.defaults. Should it also edit either or both of the other 2?

[PeterSuh-Q3]

The power_limit item began appearing in DSM 7.2-64570 U2. If this item is missing, NVme will not be recognized. It is not a hindrance just because it was previously used in an unrelated previous version.

[oriddlero]

Hello everyone, just wanted to confirm that my DS1621xs+ with DSM 7.2-64570 Update 3 is safe to run this? From what I gather there is an additional script (libsynonvme.so.1) I need to run after running the latest version of the main script?

Also, just for clarity:

1. Where do i find "libsynonvme.so.1"
2. I guess I should not update DSM beyond my current version without checking here first just in case or i risk losing my volume.
3. As long as as it is reported here that the script is safe to run on a newer version of DSM I can run the script again on boot and the volume will appear again without any data loss?
4. Has anyone had success with running Dockered PLEX on the M.2 volume, while pointing the content/media directories to the magnetic volumes? I read somewhere someone had a lot of trouble with this and I'm a bit nervous to move my Plex dockers.

Thank you in advance for any input!

[007revad]

Only containers with volumes configured should need editing.

I have a script that will create .yml files from all your running docker containers (or just one if you specify the container). See https://github.com/007revad/Docker_Autocompose

It requires Red5d/docker-autocompose (or gerkiz/autocompose) be installed in docker. Red5d/docker-autocompose or gerkiz/autocompose should not be started in docker (just installed).

It will create a folder with today's date like 20230907_docker-autocompose in the folder you set in the script. So you can have backups of previous container setups.

Then just do a search and replace in the .yml files to replace volume1 with volume2 (for example).

[007revad]

PS you can move your docker share to the new volume in "Control Panel > Shared Folders > select docker share > change Location".

[oriddlero]

Reporting back. I can’t believe it, I’m done!! Around ~4 hours to migrate everything. If some of these containers would have not came over nicely it could’ve easily turned into a week of work!

Anyhow, I’m going to outline my process here for the next guy as I am sure anyone creating these scripted NVME arrays will want to likely migrate packages as well. I’m sure there might be easier ways to do this but this made me feel safe and worked pretty much 100% for me.

• Upgrade DSM to the latest version so you get container manager, it’s a huge improvement over the old Docker manger.
• Stop all docker packages and use drop down to select “container:container_settings_container” export them individually to a directory as .txz files. Clean AF
• Uninstall / reinstall container manager to volume2
• Stop container manager
• Move Docker DIR from VOL1 to VOL2 "Control Panel > Shared Folders > select docker share > change Location"
• individual containers – import each of your export files specifying the same subdirectory under docker
• defined projects - just give it a name, and point to the doctor subdirectory of the project, select your YAML from that directory and launch/build
• now just go into each of your packages under settings and change Volume1 to Volume2 where necessary…, for projects obviously edit the YAML file the same way
• DONE! PHEW!

Thank you to everyone in this thread, it gave me the courage to proceed with this whole crazy ordeal!

Using those NVME slots for CACHE was pretty much a waste of hardware, now all of my packages have increased in performance exponentially!

Next steps: Automated Container Backups

Does anyone know of a fancy script that could do something like: stop all containers > export full .txz backup for each container > copy docker directory from vol1 to vol2

I don’t plan on updating DSM anytime soon, and although I have RAID1 on my NVME’s, in my experience is best to be proactive when it comes to data backups with workarounds like this in place. If these docker containers go poof it would be detrimental. For now I’ll do manual backups but it would be nice to be automated in the most effective, efficient way possible.

Once again, thanks!

[007revad]

Does anyone know of a fancy script that could do something like: stop all containers > export full .txz backup for each container > copy docker directory from vol1 to vol2

No, but I could whip one up :o)

[oriddlero]

That would be epic and super helpful to the community I'm sure! I spent a chunk of time googling it last night and I could not find anything that seemed proper.

Also, I can't remember where I read it and if it was your script or not but there was a script you could run Post any future DSM updates. I would probably just set it as a manual, scheduled task so it does not run on every reboot. but at least it would be there in the future if DSM comes out with any interesting worthy updates beyond current.

[arnays]

Hello everybody

I have a question:

May I use now that applied the scripts on my ds720+ and everything with m2 works fine, SSD disks too?

Thanks in advance,

Arnays

[oriddlero]

the top post says it will work fine for your 720+

[arnays]

But, SSD drive as well?. I'm not talking about M2 Drives.

[oriddlero]

SSD's in the trays are treated as normal hard drives, no? this script is for the detection of M.2. are you having some kind of trouble identifying your SSD's as drives Due to SYNO compatibility list or something?

[007revad]

SATA SSD drives (and SAS SSD drives) have always been able to be used for volumes in DSM from within storage manager, just like SATA HDDs and SAS HDDs.

DSM won't let you mix drive types in the same storage pool. So you can't a storage pool made up of SATA SSDs and NVMe drives.

[arnays]

Hi

First of all, I want to give you thanks for your replies.

No, I'm not having any problems because I wanna know before use ANY BRAND (and model) SSD in the trays. but I'll keep you updated about the subject.

Thanks again.

[007revad]

@PeterSuh-Q3

DS3622xs+ and RS4021xs+ have an issue where the latest version 7.2-64570 cannot be used

Are you saying that people running DS3622xs+ and RS4021xs+ in Xpenology with 7.2-64570 update 1 or update 2 can create NVMe volumes in storage manager?

DSM will only let users create a volume on NVMe drives if those NVMe drives are in internal M.2 slots. For NVMe drives in PCIe adaptor cards they'd need to use https://github.com/007revad/Synology_M2_volume

[PeterSuh-Q3]

Thanks, I will check.

[PeterSuh-Q3]

I haven't compared both of your scripts.
Is there a separator to distinguish between the internal M.2 NVMe and the M.2 NVMe on the PCIE adapter?
How are they differentiated in device information?

[007revad]

You can find if the NVMe drive is on the motherboard or an adaptor card with: synodisk --m2-card-model-get /dev/nvme0n1

• Returns the M.2 adaptor card model if /dev/nvme0n1 is in an M.2 PCIe card. e.g. M2D18
• Returns "Not M.2 adapter card" if /dev/nvme0n1 is in an internal slot.

In storage manager an M.2 drive in a PCIe card shows as "NVMe Drive n-n"

And synodisk --enum -t cache returns a slot id number:

************ Disk Info ***************
>> Disk id: 1
>> Slot id: 1
>> Disk path: /dev/nvme0n1

In storage manager an M.2 drive in an internal slot shows as "NVMe Drive n"

And synodisk --enum -t cache does not return a slot id number:

************ Disk Info ***************
>> Disk id: 1
>> Disk path: /dev/nvme0n1

[007revad]

The difference between my 2 M2 scripts is listed here:
https://github.com/007revad/Synology_enable_M2_volume#how-is-this-different-to-the-synology_m2_volume-script

[Garyaev-dev]

Hello!
After using the script, nothing worked. The disk does not appear in the manager.

~$ sudo -i /volume1/files/syno_enable_m2_volume.sh
Synology_enable_M2_volume v1.1.13
DS723+ DSM 7.2.1-69057-3

StorageManager 1.0.0-0017

Using options:
Running from: /volume1/files/syno_enable_m2_volume.sh
File already backed up.

Checking file.
202250 = 3160a
0003160a: 803E 00B8 0100 0000 9090 488B

File already edited.

[007revad]

Did the NVMe drive show up in storage manager before you ran the script?

Did you reboot after running the script?

[Garyaev-dev]

NVme was not displayed before the script, and is not displayed after the script.
Yes, there was a reboot.
Version DSM 7.2.1-69057-3
Synology DS723+
NVME WD Green M.2 2280 480 Gb

[007revad]

It sounds like DSM is not seeing the NVMe drive. It could be faulty.

Or maybe it's not making a good connection in the M.2 slot.

1. Shut down the DS723+.
2. Remove the NVMe drive.
3. Reinsert the NVMe drive.
4. Turn on the DS723+ and check in storage manager.

What do these commands return?

ls /run/synostorage/disks | grep nv

ls /sys/block | grep nv

[Garyaev-dev]

Hello.
Took action.
The disk did not appear in the storage manager.
The above commands did not produce anything.

[007revad]

Try switching off the NAS, remove the NVMe drive, check there's no dust in the M.2 slot, reinsert the M.2 drive a few times then turn on the NAS.