Jump to content
XPEnology Community

NVMe cache support


advin

Recommended Posts

2 hours ago, humagets said:

is it possible to upgrade DS3617xs DSM 6.2.2-24922 Update 6 to DSM version 7.0.1 without data loss?

disable/flush and remove!!! cache before upgrading to 7.0(.1), no cache no problem

you would have to wait for a new patch to get nvme cache working again in 7.0 or 7.1

Link to comment
Share on other sites

5 hours ago, IG-88 said:

disable/flush and remove!!! cache before upgrading to 7.0(.1), no cache no problem

you would have to wait for a new patch to get nvme cache working again in 7.0 or 7.1

Only possible cache would be SSD cache so this should not be necessary.  But probably the best conservative move.

 

8 hours ago, humagets said:

is it possible to upgrade DS3617xs DSM 6.2.2-24922 Update 6 to DSM version 7.0.1 without data loss?

This is the wrong place to ask this question FWIW

Link to comment
Share on other sites

edit: virtualbox got some updates and has nvme disks too, so i tested my patch and only the 2nd nvme ssd seems to work (not critical), so i removed the patch, only read cache wouled not that useful

edit2:

just to see what happens i added 4 nvme's and 3 oth them where green, one red but it was not possible to build a cache, non of the disks filfilled the requirements, the critical (red) was a nvme ssd but not usable and the other three where shown as nvme hdd's (and as hdd's obviously they dont work), also only one nvme slot was shown as used (interestingl that was one of the nvme hdd's)

image.png.44aa7ca67ae0ba7623d4a24ce7e6ce22.png

 

image.png.6c8e0198bc5412d72a3ac9d69f9eac91.png

 

image.thumb.png.6df17f8b5c36c7718a606a16d9d583f2.png

 

 

Edited by IG-88
Link to comment
Share on other sites

On 3/12/2022 at 4:16 PM, alienman said:

FYI, in DSM 7.0 DS3622xs+ virtual nvme disks (ESXi 7) are detected as cache disks when configuring them:

https://xpenology.com/forum/topic/58072-how-to-have-ds3622xs-recognize-nvme-ssd-cache-drive-maybe-works-on-other-models/?do=findComment&comment=269979

 

still i think you cant use it as cache because on 7.0 is not detecting it as ssd. on 6.2.3 works because you can use scsi but on this version whatever i tried it didnt recognize the virtual drive if i configure it as scsi.

Link to comment
Share on other sites

19 hours ago, giorgosperi said:

 

still i think you cant use it as cache because on 7.0 is not detecting it as ssd. on 6.2.3 works because you can use scsi but on this version whatever i tried it didnt recognize the virtual drive if i configure it as scsi.

That's not true, see this:

 

root@DSM:~# synodisk --isssd /dev/nvme0n1
dev:/dev/nvme0n1 is SSD

 

If you use the patch to discover the VNME devices on other PCI slots, then it will work with DSM 7.0.1-42218 with redpill configured for DS3622xs+ using a virtual NMVE device of ESXi 7. So we only need to solve the SMART data of the virtual NMVE devices, and we'll have all needed: physical and virtual devices, HDD or SSD, connected to DSM 7.0. Please, forget DSM 6.x !!

 

Link to comment
Share on other sites

On 3/19/2022 at 3:42 PM, alienman said:

That's not true, see this:

 


root@DSM:~# synodisk --isssd /dev/nvme0n1
dev:/dev/nvme0n1 is SSD

 

If you use the patch to discover the VNME devices on other PCI slots, then it will work with DSM 7.0.1-42218 with redpill configured for DS3622xs+ using a virtual NMVE device of ESXi 7. So we only need to solve the SMART data of the virtual NMVE devices, and we'll have all needed: physical and virtual devices, HDD or SSD, connected to DSM 7.0. Please, forget DSM 6.x !!

 

 

You think that maybe its not recognizing because i did for DS315xs ?

Thanks for the response...

Link to comment
Share on other sites

3 hours ago, giorgosperi said:

 

You think that maybe its not recognizing because i did for DS315xs ?

Thanks for the response...

Hi @giorgosperi,

 

I don't want to be rude. I understood you mentioned that it can't be detected as a SSD. So if the problem is the target platform (DS315xs vs DS3622xs+), then we know now that it's preferable to use the second, as it could detect both types (HDD and SSD) as your preference for virtual disks.

 

I apologize for the misunderstanding!

Link to comment
Share on other sites

3 hours ago, alienman said:

Hi @giorgosperi,

 

I don't want to be rude. I understood you mentioned that it can't be detected as a SSD. So if the problem is the target platform (DS315xs vs DS3622xs+), then we know now that it's preferable to use the second, as it could detect both types (HDD and SSD) as your preference for virtual disks.

 

I apologize for the misunderstanding!

no worries sorry also for the questions that i have. to be honest i followed a guide for 3615xs. do you have one to follow for 3622 if you can please? on your setup it recognizes the ssd as ssd even sata configured?

Link to comment
Share on other sites

Hi @giorgosperi,

 

To create the Virtual Machine and install on it the redpill-tinycore I've used this basic guide: https://www.tsunati.com/blog/xpenology-7-0-1-on-esxi-7-x. With some tips from: https://xpenology.club/install-dsm-7-on-baremetal-or-vm/

 

And I've added some custom tweaks:

- After download the (last) VMDK of the redpill-tinycore I upload it to my ESXi server, and before adding the disk to the VM I do a VMDK copy: "vmkfstools -i tinycore-redpill.v0.4.6.vmdk -d thin thin-tinycore-redpill.v0.4.6.vmdk". The reason is because the image is created using the qemu tools, and it could generate errors. So I prefer to create a new image from the source, and set the type that I want to use (in this case "thin").

- For the Hard Disk controllers in the VM I use: 1 SATA (0:0) for the redpill bootdrive; 1 SATA (1:0) for the HDD disks (configured as SATA); 1 pvscsi (0:0) for the SSD Cache disks; 1 NMVe only for testing as for nvme disks the SMART fails (lacks a redpill shim). In the future I'll try to passthrough real NVMe disks.

- All HDD (vmdk or RDM) are connected to the second SATA controller. And all SSD (vmdk or RDM) are connected to the pvSCSI controller. Remember to edit the .VMX file to add the corresponding flag of force-SSD-type: scsi0:0.virtualSSD = "TRUE".

- Also I've installed one open-vm-tools package: 

But for this we need to work on finishing the shutdown support.

 

For the rest, it's more or less what you prefer to do. Perhaps a new guide "How to install DSM 7.0 in ESXi with HDD and CACHE" could be writed for this forum. Don't think so?

Regards.

 

Edited by alienman
  • Like 1
Link to comment
Share on other sites

6 hours ago, alienman said:

Hi @giorgosperi,

 

To create the Virtual Machine and install on it the redpill-tinycore I've used this basic guide: https://www.tsunati.com/blog/xpenology-7-0-1-on-esxi-7-x. With some tips from: https://xpenology.club/install-dsm-7-on-baremetal-or-vm/

 

And I've added some custom tweaks:

- After download the (last) VMDK of the redpill-tinycore I upload it to my ESXi server, and before adding the disk to the VM I do a VMDK copy: "vmkfstools -i tinycore-redpill.v0.4.6.vmdk -d thin thin-tinycore-redpill.v0.4.6.vmdk". The reason is because the image is created using the qemu tools, and it could generate errors. So I prefer to create a new image from the source, and set the type that I want to use (in this case "thin").

- For the Hard Disk controllers in the VM I use: 1 SATA (0:0) for the redpill bootdrive; 1 SATA (1:0) for the HDD disks (configured as SATA); 1 pvscsi (0:0) for the SSD Cache disks; 1 NMVe only for testing as for nvme disks the SMART fails (lacks a redpill shim). In the future I'll try to passthrough real NVMe disks.

- All HDD (vmdk or RDM) are connected to the second SATA controller. And all SSD (vmdk or RDM) are connected to the pvSCSI controller. Remember to edit the .VMX file to add the corresponding flag of force-SSD-type: scsi0:0.virtualSSD = "TRUE".

- Also I've installed one open-vm-tools package: 

But for this we need to work on finishing the shutdown support.

 

For the rest, it's more or less what you prefer to do. Perhaps a new guide "How to install DSM 7.0 in ESXi with HDD and CACHE" could be writed for this forum. Don't think so?

Regards.

 

let me check. thanks for that. i was trying yesterday for tinycore i installed it also on my esxi but i couldnt see the gui i guess the vmdk was without the gui. but when i tried to do sftp or ftp or with putty it didnt let me log in. i guess i did something wrong on the installation.

my previous installation i did it on an ubuntu that i have but there is missing some stuff that tinycore has.

 

yeah probably a guide that has whatever workarounds and fixes because right now i find multiple informations and guides here and there.

 

*you were right with this guide tinycore worked. so now i m moving to start building the image etc

Edited by giorgosperi
Link to comment
Share on other sites

  • 3 months later...

Hello everyone, sorry i don't know if i'm posting this message on the right section, but i will post in anyway

My config is a hpe server ml30 gen10 i got 6 Hdd and 1 nvme

I have dsm 7 ds918+ installed, my nvme wasn't detected after the install i had to do a little tweak (found here : https://nguyenvinh-net.translate.goog/xpenology-mod-driver-de-nhan-o-nvme-tren-ds918-chay-dsm-7.html?_x_tr_sl=vi&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=sc ) for it to work.

After this procedure, my nvme was detected and i did a test by creating a cache ssd and i succed.

Later on, i deleted this cache ssd and created a new volume in shr with all 6 of my drives. The process of creating this new volume is quite long and it is still going.

My problem is that when i got back to check on how far i'm at creating this new volume, i noticed my that my nvme is no more detected, i can now longer see nor on the main page  nor on the hdd/ssd side. When i run the command "nvme lis" i do not get anything anymore. The folder /dev/nvme0n1 doesn't seem to exist anymore.

Still waiting for my shr to create so i can reboot and whats going on, it's at 55% right now

 

Edited by zezer974
  • Like 1
Link to comment
Share on other sites

@giacomoleopardo @Peter Suh

 

AFAIK the NVMe cache support is very well implemented in DS918+ with all the DSM up to the current 7.1 version; It's based upon the patching process of the libsynonvme.so.1 file in /usr/lib64 dir with the correct PCI addresses (related to your motherboard). 

 

As for DS920+ (or other models too), the same libsynonvme.so.1 file doesn't contain ANY DSxxx model's reference inside its binary contents, so that the patching process is not available anymore. This leave the chances to have a correct NVMe cache support to only one method (at least that I Know!): to modify or to create, if it doesn't exist, the following file: 

 

/etc.defaults/ConfigurationPorts 

 

to add the correct PCI addresses of NVMe's drives, i.e. : 

 

[PCI]

pci1="0000:00:001b"

pci2="0000:00:001c"

 

does anyone have experience with this latest process? 

how  does the ARPL's fabio's dtbpatch ext. can get the job done automatically? And what can we do if the patch doesn't work? 

Thanks in advance to all who will answer.

 

Link to comment
Share on other sites

6 minutes ago, Hackaro said:

@giacomoleopardo @Peter Suh

 

AFAIK the NVMe cache support is very well implemented in DS918+ with all the DSM up to the current 7.1 version; It's based upon the patching process of the libsynonvme.so.1 file in /usr/lib64 dir with the correct PCI addresses (related to your motherboard). 

 

As for DS920+ (or other models too), the same libsynonvme.so.1 file doesn't contain ANY DSxxx model's reference inside its binary contents, so that the patching process is not available anymore. This leave the chances to have a correct NVMe cache support to only one method (at least that I Know!): to modify or to create, if it doesn't exist, the following file: 

 

/etc.defaults/ConfigurationPorts 

 

to add the correct PCI addresses of NVMe's drives, i.e. : 

 

[PCI]

pci1="0000:00:001b"

pci2="0000:00:001c"

 

does anyone have experience with this latest process? 

how  does the ARPL's fabio's dtbpatch ext. can get the job done automatically? And what can we do if the patch doesn't work? 

Thanks in advance to all who will answer.

 

 

 

First off, you need to check the junior log to see if fabio's dtbpatch ext tried NVMe mapping.

For Junior log, log in as TTYD as shown below and look at the log below.

 

http://<youripaddr>:7681/
id : root / pw : ( no password )

cat /var/log/*rc*

 

Please attach the contents of this log using spoilers.

Link to comment
Share on other sites

16 hours ago, Peter Suh said:

 

 

First off, you need to check the junior log to see if fabio's dtbpatch ext tried NVMe mapping.

For Junior log, log in as TTYD as shown below and look at the log below.

 

http://<youripaddr>:7681/
id : root / pw : ( no password )

cat /var/log/*rc*

 

Please attach the contents of this log using spoilers.

 

My main machine is a Mac one. I've installed HomeBrew and followed these instructions . At this point I'm completely stuck because if I put my NAS IP's address in Safari browser's window on port 7681 I get repeatedly two messages: 

 

"connection closed"

"315x67"

 

which tells me the problem occurs on my NAS.

 

I can confirm you that ttyd has been installed on NAS side during TC installation:

-------

[#] Downloading remote file https://github.com/tsl0922/ttyd/releases/download/1.6.3/ttyd.x86_64 to /home/tc/redpill-load/custom/extensions/redpill-misc/ds920p_42218/ttyd
######################################################################################################################### 100.0% 

-------

 

But, as you can see, with the command:

 

"systemctl status ttyd"

 

I get this result: 

● ttyd.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)
 

-----

So it seems to me that the service is not loaded. 

 

Any hint? What am I doing wrong?

  • Like 1
Link to comment
Share on other sites

3 hours ago, Hackaro said:

 

My main machine is a Mac one. I've installed HomeBrew and followed these instructions . At this point I'm completely stuck because if I put my NAS IP's address in Safari browser's window on port 7681 I get repeatedly two messages: 

 

"connection closed"

"315x67"

 

which tells me the problem occurs on my NAS.

 

I can confirm you that ttyd has been installed on NAS side during TC installation:

-------

[#] Downloading remote file https://github.com/tsl0922/ttyd/releases/download/1.6.3/ttyd.x86_64 to /home/tc/redpill-load/custom/extensions/redpill-misc/ds920p_42218/ttyd
######################################################################################################################### 100.0% 

-------

 

But, as you can see, with the command:

 

"systemctl status ttyd"

 

I get this result: 

● ttyd.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)
 

-----

So it seems to me that the service is not loaded. 

 

Any hint? What am I doing wrong?

 

There are cases where the ttyd daemon is not running due to some error on junior. Even if you are not in junior state, you cannot connect to ttyd.
ttyd is not a program that needs to be installed even on a Mac.
Simply use any web browser.
Safari doesn't matter.

This is what it looks like when I logged in to my junior in Safari.

 

79213823_2022-07-2710_08_14.thumb.png.83b1b28c48647d96fa410d1fb5f71f1d.png

 

If ttyd cannot connect, it forcibly starts the telnet daemon.
Alternatively, you can connect via telnet.

 

http://<youripaddr>:5000/webman/start_telnet.cgi

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

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.

×
×
  • Create New...