Inkompatible NVMe SSD verhindern Ruhezustand

[Flint]

Hallo zusammen

Ich besitze eine DS918+ und hatte zwei NVMe SSD (Corsair Force MP510 240GB) als SSD-Cache eingebaut. Bislang lief alles rund. Neulich ist mir jedoch aufgefallen, dass die NAS den Ruhezustand nicht mehr erreichen konnte und machte mich auf die Suche. Zusammen mit dem Support kam aufgrund folgender Logeinträge die Erkenntnis, dass der SSD Cache dafür verantwortlich sein muss:

/var/log/messages

[...] synostoraged: nvme_disk_vender_get.c:47 Fail to get vendor name of 0x1987

wurde 1x pro Minute ins Log geschrieben

Die verwendeten NVMe Module erscheinen tatsächlich nicht auf der Kompatibilitätsseite (https://www.synology.com/en-au/comp...cts&model=DS918+&category=m2_ssd_internal&p=1).

Den Cache zurückgeschrieben und ausgebaut, funktionierte der Ruhezustand auf Anhieb wieder. Soweit so gut.

Aber: bis vor einigen Wochen hat der Ruhezustand trotz SSD Cache immer funktioniert! Irgend etwas muss in der Zwischenzeit passiert sein. Ich tippe mal auf das letzte Firmwareupdate 6.2.4-25556, welches am 22.03.21 released wurde. Leider bringe ich kein Downgrading hin um das zu reproduzieren. Ich tippe vorsichtig auf einen Bug resp. auf das simple Fehlen der Herstellerbezeichnung "Corsair" in der Firmware, weshalb die NAS diese Fehler dauernd ins Log schreibt. Natürlich mit der Konsequenz, dass der Ruhezustand nicht mehr klappt.

Kann ja nicht sein, dass funktionierende Module plötzlich inkompatibel werden. Beschwerde ist beim Support noch hängig...

Hat jemand ähnliche Erfahrungen mit der Firmware gemacht? Geschieht dies auch mit anderen Modulen, die nicht auf der Liste stehen?


Liebe Grüsse
Alex

 

[Benares]

Kann ja nicht sein, dass funktionierende Module plötzlich inkompatibel werden

Kann schon sein. Schau dich mal über die Konsole (ssh) unter /var/lib um. Da gibt es u.a. auch Verzeichnisse wie disk-compatibility oder memory-compatibility (bei dir vielleicht auch nvme-compatibility?) mit umfangreichen JSON-Files mit Angaben zu kompatiblen Geräten. Da kann es schon sein, dass nach einem DSM-Update ein Gerät plötzlich als nicht mehr kompatibel gilt und das geloggt wird. Das muss ja nicht heißen, dass das Gerät nicht mehr funktioniert, Synology möchte halt immer mehr das eigene Zeugs verkaufen.

Kannst ja mal schauen, ob du eine entsprechende Datei findest. Evtl. kannst du ja deine NVMe SSDs ergänzen
Für Notepad++ gibt es übrigens ein Plug-In um JSON-Files schöner darzustellen.

 

[Flint]

Schau dich mal über die Konsole (ssh) unter /var/lib um. Da gibt es u.a. auch Verzeichnisse wie disk-compatibility oder memory-compatibility (bei dir vielleicht auch nvme-compatibility?) mit umfangreichen JSON-Files mit Angaben zu kompatiblen Geräten.

Ja genau, in der /var/lib/disk-compatibility/ds918+_host.db finde ich Einträge wie z.B.

{"model":"KINGSTON SA2000M8250G","firmware":"S5Z42102","rec_intvl":[1]},

Das Kingston A2000 ist ein NVMe SSD aus der Kompatibilitätsliste. Mein Corsair fehlt somit in dieser Liste.
Kann ich das dort einfach hinzufügen? Was passiert mit den Dateien "ds918+_host.db.bak" und "ds918+_host.db.new"? Ich nehme mal an, die Liste wird beim nächsten FW-Update wieder überschrieben?

 

[Benares]

Ich kann da auch nur Vermutungen anstellen, so genau weiß das hier keiner. Auch die Logik innerhalb der Files muss man erstmal richtig verstehen.
Aber du kannst ja mal einige Versuche unternehmen und anschließend hier darüber berichten. Vielleicht findet sich auch jemand hier im Forum, der auch eine DS918+, aber mit einer etwas älteren DSM-Version, hat, damit ihr vergleichen könnt.

Klar, bei weiteren Updates würden deine Anpassungen vermutlich überschreiben. Aber du weißt ja dann, wo du hinlangen musst.

 

[Flint]

Ich habe mal rumprobiert und es bisher nicht hinbekommen. Ich habe auch mal unter /sys/class/block/ nachgesehen, wie sich die NVMe überhaupt identifizieren. Zuerst "sda", welches eine WDC Festplatte ist. Danach das "nvme1n1".

ash-4.3# ls /sys/class/block/sda/device/
block                               evt_soft_threshold_reached  queue_type               syno_disk_latency_other_hist  syno_wcache
bsg                                 generic                     rescan                   syno_disk_latency_read_hist   timeout
delete                              inquiry                     rev                      syno_disk_latency_stat        type
device_blocked                      iocounterbits               scsi_device              syno_disk_latency_write_hist  uevent
device_busy                         iodone_cnt                  scsi_disk                syno_disk_serial              unload_heads
driver                              ioerr_cnt                   scsi_generic             syno_fake_error_ctrl          vendor
eh_timeout                          iorequest_cnt               scsi_level               syno_idle_time                vpd_pg80
evt_capacity_change_reported        modalias                    state                    syno_pwr_reset_count          vpd_pg83
evt_inquiry_change_reported         model                       subsystem                syno_sata_error_event_debug
evt_lun_change_reported             power                       sw_activity              syno_scmd_min_timeout
evt_media_change                    queue_depth                 syno_deep_sleep_ctrl     syno_spindown
evt_mode_parameter_change_reported  queue_ramp_up_period        syno_deep_sleep_support  syno_standby_syncing

ash-4.3# ls /sys/class/block/nvme1n1/device/
dev  device  firmware_rev  model  nvme1n1  power  reset_controller  serial  subsystem  syno_force_timeout  syno_idle_time  uevent

Grosser Unterschied. Gemäss /var/log/messages findet er ja den vendor nicht. In /sys/class/block/nvmr1n1/device gibt es keinen vendor.

Fehlt der Synology irgend einen Treiber? Oder die SSD ein Firmwareupdate?

Falls noch jemand eine Idee hat, lasst es mich bitte wissen.

 

[Benares]

Mmh, probier mal, was "hdparm -i /dev/sda" und "hdparm -i /dev/nvme1n1" im Vergleich dazu alles herausfindet.
Du meinst also, dass er den vendor nicht ermitteln kann?

Ich hatte die Meldung in #1 so interpretiert, dass er den vendor evtl. schon weiß, aber kein passendes Gerät in den compatibility-Dateien findet. Aber deine Vermutung könnte natürlich auch zutreffen.

 

[Flint]

hdparm scheint auch Mühe zu haben:

ash-4.3# hdparm -i /dev/sda

/dev/sda:

Model=WDC WD30EFRX-68EUZN0, FwRev=80.00A80, SerialNo=WD-WMC4N0615231
Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=unknown, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=5860533168
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes:  pio0 pio3 pio4
DMA modes:  mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=no WriteCache=enabled
Drive conforms to: Unspecified:  ATA/ATAPI-1,2,3,4,5,6,7

* signifies the current active mode

ash-4.3# hdparm -i /dev/nvme1n1

/dev/nvme1n1:
HDIO_DRIVE_CMD(identify) failed: Inappropriate ioctl for device
HDIO_GET_IDENTITY failed: Inappropriate ioctl for device

Ich bin vom Vendor-Problem ausgegangen, da auch im Speicher-Manager die Marke der NVMe nicht angezeigt wird:

 

[synfor]

Ich hatte die Meldung in #1 so interpretiert, dass er den vendor evtl. schon weiß, aber kein passendes Gerät in den compatibility-Dateien findet.

Für mich sieht die eher so aus, als ob der Vendor-ID keinen Namen zugeordnet werden kann. Wobei, warum muss das im Minutentakt in einer Endlosschleife erneut versucht werden und woher kommt die Vendor-ID, wenn die Abfrage fehlschlägt?

 

[Dany28]

Gibt es hier noch neuere Erfahrungen? Meine Corsair MP600 als SSD-Cache werden auch als Unknown angezeigt....