Beiträge von d0b

Übergangslösung gefunden, ist etwas teurer aber besser als kein Support:

SEAGATE EXOS X14 Enterprise Capacity 10TB 512e/4kn 7200rpm SAS 12Gb/s 256MB cache 8,9cm 3,5Zoll 24x7 BLK (ST10000NM0528)

Sorry fürs Thread ausgraben, hat nur so gut gepasst weil es immer noch keine Infos zu 4k gibt.

Ich habe 10/2018 diverse 10TB SAS Modelle der Hersteller Seagate, HGST, Toshiba in das Prüfungsformular eingegeben mit dem Ergebnis das bis heute keine der aktuellen Platten da auftaucht.

Am liebsten würde ich jetzt Seagates`ST10000NM0206 (10TB 4k SAS - nicht supportet) verbauen, da diese der Nachfolger der ST10000NM0096 (10TB 512e SAS - supportet aber nicht verfügbar) ist. Das trifft leider auch auf aktuelel HGST / Toshiba platten zu.

Gerne nehme ich auch Tipps aus der Community entgegen was man sonst aktuelles einbauen könnte in mit 10TB und SAS was man am besten noch in einen halben Jahr nachkaufen kann.

Ich hab größtenteils REXP1620U-RP im Einsatz, d.h. die können SAS

Mein Eindruck in letzten Jahr ist das QNAP am Support etwas zu sparen scheint QNAP Sales Leute werden zusammengestrichen, Support lässt nach bzw. hat kein ausreichenden KnowHow mehr und keinen Einfluss auf solche Prozesse wie Kompatibilitätslisten -> OTON: Macht ja alles Taiwan ...

Wenn das so bleibt werde ich mich langfristig im KMU Bereich Umorientieren müssen.

Falls Du nicht meinst das alle 48Ports 10Gbit/s & PoE+ können sollten -> sondern 48Ports 1Gbit/s & PoE+ mit 10Gbits Uplink:

• FS S5500-48T8SP - 48-Port-Gigabit Stapelbar L3 Managed PoE+ Switch mit 8 SFP+, 500W -
• SFP+ Transceiver Modul - 10GBASE-T SFP+ Kupfer RJ-45 30m für FS Switches

Entschuldige meine Latenz, bin nicht so oft hier

Aktuell ist bei Jumbo Frame 9k MTU.

Wie schon erkannt haben die Switche ein sehr gutes Preis/Leistung Verhältnis. Auch Transceiver sind sehr günstig, gibts auch mit gelabelten DoM`s - z.B. 10GB SR LC MM für 15€.

Ich bin mit den Switchen bisher sehr zufrieden, man sollte beim bestellen nur auf die Lieferdauer achten, da diese ca. 4-6 Wochen betragen kann wenn es nicht im EU-Lager vorrätig ist.

Bestelltip, falls noch nicht im Sortiment vorhanden & man eh dort einkaufen möchte.

Entschuldigt die späte Rückmeldung! zur Doku hier noch die Antworten & Auflösung.

Der Switch hat natürlich ein CLI. Fehlerursache war die LACP Config auf Switch Seite, "static" anstatt "dynamic active". Also: Layer 8 Fehler - Danke Crazyhorse!

Verwirrt hatte mich das QNAP NAS. Hier waren beide Ports Up und es wurden keine Fehler gemeldet. Auch der Switch hatte witzigerweise nichts zu meckern.

Also habe ich die Konfiguration auf beiden Seiten nochmal neu angelegt.

Switch

lacp system-priority 2000 
port-channel dynamic-load-balance enable 
interface eth-0-1
  no shutdown
  channel-group 1 mode active
  exit
interface eth-0-2
  no shutdown
  channel-group 1 mode active
  exit  
interface agg 1  
  jumboframe enable                               
  exit

copy running-config startup-config                

Wie man sieht, sehr ähnlich zu Cisco. Hier noch ein paar Befehle zum Troubleshooten.

show channel-group summary                        
show interface agg 1
show lacp {counters | internal | neighbor | sys-id}  

• Switch LACP Status sagt alles OK, auch keine Warnings. o.ä.
• Ist ein MAC-Adressen basiertes L2
• Ist die neueste FW-Rev. auf dem Switch und die neuste stable FW-Rev. auf dem Server

Der Fehler ist mir bei 1Gbit/s Kuper basierten LACP noch nie untergekommen.

• Alle Clients + Server sind übrigens mit statischen Ipv4 Adressen konfiguriert.

Hallo zusammen,

ich habe hier ein frisches Setup, relativ simpel

• 1x QNAP TVS872XU-RP (Anbindung mit 2x10Gbits via LACP (802.3ad dynamic + MTU=9000) an einen Managed Switch (FS S5800-8TF12S), welcher natürlich ebenfalls entsprechend konfiguriert ist.

• 5x Clients (iMac`s mit OS 10.14.5 Mojave) angebunden je mit QNA-T310G1S (TB3 auf SFP+ 10Gbit/s) mit MTU=9000

Der Switch hängt mit 1x Gbit/s an einen Router der das Netzwerk mit Internet versorgt.

Problem:

3 der 5 Clients können alle Geräte sowie das Internet über das o.g. Netzwerk erreichen, jedoch nicht den Server. Ping Tests von der CLI des Switch zeigen, das dieser alle Clients erreichen kann. Interessanterweise kann der Switch den Server gar nicht pingen. Die Clients die den Server erreichen können haben keine Probleme, Clients den Server nicht erreichen können, bekommen zwar mit seinen NETBUI Namen angezeigt können diesen aber weder pingen noch auf dessen Dienste erreichen (SMB, WEB GUI)

Sobald ich ich einen Link weg nehme, d.h. 1x LWL ziehen, sagt der Server natürlich das Bonding ist degraded aber dann können alle Clients auch wieder den Server erreichen. Es spielt keine Rolle welches der beiden Linkstrecken gezogen wird.

Für hilfreiche Tipps zur Ergreifung des Fehlers wäre ich sehr dankbar! Weitere Konfiguration & Infos teile ich gerne mit Euch =)

Grüße

Ich habe in der Zwischenzeit bereits einen neuen Server gekauft & produktiv eingerichtet, da ich selbst nicht mehr weiter wusste, der QNAP Support noch hier noch sonstwo jemand hilfreiche Tipps zur Ergreifung des Fehler liefern konnte. Schade, denn ich würde gerne mir und anderen dieses Leid in Zukunft ersparen, nun denn.

Ich habe beim aktuellen Setup alle Rechte einen Benutzer und einer Gruppe gegeben die dediziert für diese Freigabe arbeiten und die Zugriffsoption auf "ALL_Squash" gesetzt und allen den erstellten dedizierten User sowie Gruppe zugewiesen. Bisher läuft es wieder ohne Störungen seit nun 4 Wochen.

Hier noch ein paar Tips zum Troubleshooting mit NFS:

In der Nachfolgenden Fehlersuche gehen wir mal davon aus der Server die IP-Adresse 192.168.23.23 hat und der Client sich im gleichen Netz befindet mit einer abweichende IP-Adresse (z.B. 192.168.23.42).

• Physikalische Verbindung prüfen (Client: Ping 192.168.23.23)
• NFS Daemon neu starten (Server: /etc/init.d/nfs restart)
• Prüfen ob RPC Messages durch das Netzwerk gelassen werden (Firewall Log prüfen)
• Prüfen ob der entsprechende RPC Dienst läuft
  
  • Server: "rpc.nfsd -d"
  • Client: "rpcinfo -p 192.168.23.23"
• Funktioniert die Freigabe (Client: showmount -e 192.168.23.23)
• Freigabe neu verbinden (Client: umount, mount)
• Wenn es hier noch Probleme gibt Netzwerkpakete mitschneiden (z.B. mit Wireshark), ggfs. helfen nachfolgende Befehle auch den Fehler einzugrenzen (Shell):
  
  • ls -ld /pfad/zur/freigabe
  • getfacl /pfad/zur/freigabe
  • dmesg | grep NFS*
  Links: * NFS fsid: https://linux.die.net/man/5/exports

  
  

  Grüße

  
  

  
  

Hallo zusammen,

es ist wieder soweit, ich bin zwar mit meinen Latein noch nicht am ende aber vielleicht hat ja hier jemand den richtigen Tip zur Ergreifung des Fehlers.

Vorgeschichte:

Ein Qnap TS-879U-RP mit 4.2.5 FW ist ausgefallen und auch mit gezogenen Platten nicht mehr angegangen. Halb so wild, es stand ja noch ein TS-871U-RP bereit auf den migriert werden sollte. Da auf dem 871er bereits 4.3.6 FW installiert wurde, habe ich die Platten migriert und die aktuelle FW nochmal mit Qfinder installiert. Nun ging so einiges nicht mehr wie Externe Rsync Backup Jobs, LACP Netzwerkschnittstellen config etc. habe ich aber alles schon gefixt, bis auf einen NFS Fehler...

Problem:

Es gibt eine NFS Freigabe welche seit der Migration ein seltsames Verhalten aufweist, welchen ich bisher nicht auf die Schliche gekommen bin.

Die Freigabe an sich läuft, d.h. Clients haben eine statische Config welche nach wie vor funktioniert, nur kommt es jetzt sporadisch vor das $Random Ordner nicht angezeigt werden für eine Dauer von ca.5-10min, falls die Ordner die verschwinden in Zugriff waren, ist dieser innerhalb der genannten Zeit auch nicht mehr gegeben. Dieser Fehler tritt geschätzt alle 1-2Std. auf, sobald ich genauere Zeiten habe bzw. periodisches Verhalten erkennen kann würde ich das nachreichen - habe ich bisher jedoch nicht.

Troubleshooting:

Wo ist den nun der Fehler? -> Ausschlussprinzip:

• Clients: (Mac OS Mojave) Es wurden keine Änderungen vorgenommen, weshalb ich diese erstmals als Fehlerquelle ausschließe
• Server: NFS Settings sind unverändert, FW wurde von 4.2.5 auf 4.3.6. hochgezogen und ich hab ihm Kopf das auf 4.2.5 kein NFS v4 angeboten wurde, welcher aktuell aber eh deaktiviert ist.
• Verbindung: Die Physikalische Verbindund der Clients zum Server funktioniert auch wenn die Freigabe nicht verfügbar ist (ping), die beiden 10er IPs sind Arbeitsplätze welche via 10Gb LWL direkt mit dem Server verbunden sind.
  

Serverseitige Configs & Ausgaben

cat /etc/config/nfssetting

"/share/CACHEDEV1_DATA/Public" *(rw,async,no_root_squash,insecure) 

[Global]
Version = 4.2.0

[Access]
/share/CACHEDEV1_DATA/Public = TRUE
/share/CACHEDEV2_DATA/Cutedrale = TRUE
[AllowIP]
/share/CACHEDEV1_DATA/Public = *
/share/CACHEDEV2_DATA/Cutedrale = 10.0.1.11,10.0.2.21,192.168.178.90,192.168.178.91,192.168.178.92,192.168.178.93
[Permission]
/share/CACHEDEV1_DATA/Public = rw
/share/CACHEDEV2_DATA/Cutedrale = rw,rw,rw,rw,rw,rw
[SquashOption]
/share/CACHEDEV1_DATA/Public = no_root_squash
/share/CACHEDEV2_DATA/Cutedrale = no_root_squash,no_root_squash,no_root_squash,no_root_squash,no_root_squash,no_root_squash
[AnonUID]
/share/CACHEDEV1_DATA/Public = 65534
/share/CACHEDEV2_DATA/Cutedrale = 514,514,514,514,514,514
[AnonGID]
/share/CACHEDEV1_DATA/Public = 65534
/share/CACHEDEV2_DATA/Cutedrale = 105,105,105,105,105,105

cat /etc/exports

"/share/CACHEDEV2_DATA/Cutedrale" 10.0.1.11(rw,async,subtree_check,insecure,no_root_squash,fsid=d4b0c5f6caf62924f5dabad287616e8f) 10.0.2.21(rw,async,subtree_check,insecure,no_root_squash,fsid=d4b0c5f6caf62924f5dabad287616e8f) 192.168.178.90(rw,async,subtree_check,insecure,no_root_squash,fsid=d4b0c5f6caf62924f5dabad287616e8f) 192.168.178.91(rw,async,subtree_check,insecure,no_root_squash,fsid=d4b0c5f6caf62924f5dabad287616e8f) 192.168.178.92(rw,async,subtree_check,insecure,no_root_squash,fsid=d4b0c5f6caf62924f5dabad287616e8f) 192.168.178.93(rw,async,subtree_check,insecure,no_root_squash,fsid=d4b0c5f6caf62924f5dabad287616e8f)

"/share/CACHEDEV1_DATA/Public" *(rw,async,subtree_check,insecure,no_root_squash,fsid=37b143ba0ca575d37a356ab03a7a28db)

ls -ld /share/CACHEDEV2_DATA/Cutedrale

drwxrwxrwx 39 admin administrators 4096 2019-05-21 14:40 /share/CACHEDEV2_DATA/Cutedrale

getfacl /share/CACHEDEV2_DATA/Cutedrale

# file: share/CACHEDEV2_DATA/Cutedrale
# owner: admin
# group: administrators
user::rwx
user:admin:rwx
user:armin:rwx
user:guest:---
group::rwx
group:GF:r-x
group:Cutedrale:rwx
mask::rwx
other::rwx
default:user::rwx
default:user:admin:rwx
default:user:armin:rwx
default:user:guest:---
default:group::rwx
default:group:GF:r-x
default:group:Cutedrale:rwx
default:mask::rwx
default:other::---

Ich versuche aktuell herauszufinden welche Version des NFS Daemons unter 4.2.5 lief und welcher es nun unter 4.3.6. ist wenn ich v2/v3 aktiviere.

Clientseitige Configs

cat /etc/auto_nfs

Cutedrale -fstype=nfs,rw,bg,hard,intr,tcp 192.168.178.20:/Cutedrale

cat /etc/autofs.conf

AUTOMOUNT_TIMEOUT=3600
AUTOMOUNTD_MNTOPTS=nosuid,nodevi,resvport
AUTOMOUNTD_NOSUID=TRUE

cat /etc/auto_master

+auto_master        # Use directory service
/net            -hosts        -nobrowse,hidefromfinder,nosuid
/home            auto_home    -nobrowse,hidefromfinder
/Network/Servers    -fstab
/-            -static
/Qnap            /etc/auto_nfs

Ansonsten freue ich mich natürlich wenn jemand noch Hinweise hat, womit sich der Fehler eingrenzen oder finden lässt.

Stay tuned!

Grüße

Ich habe gerade alle mehrere Deutsche und Englische Qnap Foren Threads durchgelesen und anschliessend in München angerufen (Qnap Support). Es scheint so, als wüsste bisher keiner so wirklich wo der Angriffsvektor dieser Malware ist?!

(Ein Dienst mit einer ausnützbaren Sicherheitslücke)

Falls ich das überlesen haben sollte tut es mir leid, würde mich aber trotzdem über eine Rückmeldung mit der entsprechenden Antwort freuen.

Ansonsten bleibt mir nur ein Demo Gerät mit allen Ports an Internet zu hängen und über einen Monitor Port am Switch mir Wireshark selbst auf die Jagd zu gehen...

Update vom QNAP Workshop in DÜsseldorf heute!

Ich habe gerade mit Hr. Florian Schorn gesprochen und ich habe mich sehr gefreut das mein Problem mit dem SAS-Controller im nachhinein mit dem Fehlerhaften ein gesendeten Controller noch aufgeklärt wurde.

Die Hardware war OK! Die Firmware des Controllers war die Ursache des Problems, es gibt nun ein Tool um die Firmware des SAS-Controller via WebGUI zu aktualisieren - leider ist das Tool nicht öffentlich! Wer dieses Problem auch haben sollte, wendet sich am besten direkt an den QNAP Support und nimmt Bezug auf diese Problematik (SAS-Controller Firmware Fehler).

Nach 10 Tagen Downtime von 150TB Storage kann ich endlich sagen "Es läuft wieder" - der SAS-Controller war es.

Ob der SAS-Controller aber jetzt einen Hard- oder Softwarefehler hat - ist mir immer noch nicht klar. Von Qnap Support habe ich bis heute immer noch keine hilfreichen Erkenntnisse bekommen, hoffe aber das irgend jemand bei Qnap herauszufinden möchte was es jetzt genau war auch wenn das Ticket mit meinen letzten Post dort erledigt ist.

Vielleicht wird meine Idee angenommen in das Diagnose Tool einen Hardwaretest mit einzubauen, der dann merkt was kaputt ist.
Jetzt noch die ausstehende REXP1620 wieder abbestellen (zum Glück?! noch im Verzug). Wenn der 2.te SAS- Controller kommt diesen verbauen und das Setup splitten damit so etwas nicht mehr passiert + mir noch einen SAS-Controller ins Lager legen. Dann nur noch den defekten Controller einsenden (5 Monate alt).

Fazit:
Entweder die eingesetzte Hardware hoch redundant bauen & Ersatzhardware selbst lagern und nach dem Baukasten Prinzip Teile bei Fehler austauschen oder auf bewährte Hardware in diesen Segment setzen, wo Support & Hardwareverfügbarkeit im Fehlerfall gegeben sind.

Aber nach der ganzen unbezahlten Zeit & Kosten fahr ich bei den Wetter jetzt an den See und gönne mir ein kaltes Bier!

In diesen Sinne danke an das Forum & schönes Wochenende!

Wenn das so ist, wieso wird dann nach dmesg ein Treiber aus der 4.2.2 Firmware geladen obwohl auf 4.2.5 aktualisiert wurde?

Mir ist klar das die Firmware aus dem DoM bootstrapt auf die HDD`s - was mir nicht klar war ist zu welchen Zeitpunkt der Treiber für den SAS-Controller geladen wird. Diese Frage konnte ich mir aber selbst beantworten durch die dmesg Ausgabe = bereits vor dem bootstrapping.
Das führte mich zur Frage warum dieser Treiber noch auf der Version 4.2.2 ist.

- Neuer Server ist eingetroffen (Firmware: v.4.2.2)
- Firmware mit Qfinder Pro Manuell auf v. 4.2.5 aktualisiert
- Alter & Neuer Server heruntergefahren
- PCIe SAS Controller + SFP LWL Karte getauscht
- Neuen Server gestartet: findet keine REXP
- DMESG Ausgabe (gleicher Fehler wie vorher)

[    6.538529] mpt3sas0: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem (8136304 kB)[    6.538541] mpt3sas0: fault_state(0x26b5)![    6.538542] mpt3sas0: sending diag reset !!...snip...[    7.437921] mpt3sas0: diag reset: SUCCESS[    7.519883] mpt3sas0: IOC Number : 0[    7.519932] mpt3sas 0000:01:00.0: irq 56 for MSI/MSI-X[    7.519937] mpt3sas 0000:01:00.0: irq 57 for MSI/MSI-X[    7.519941] mpt3sas 0000:01:00.0: irq 58 for MSI/MSI-X[    7.519947] mpt3sas 0000:01:00.0: irq 59 for MSI/MSI-X[    7.519985] mpt3sas0-msix0: PCI-MSI-X enabled: IRQ 56[    7.519986] mpt3sas0-msix1: PCI-MSI-X enabled: IRQ 57[    7.519986] mpt3sas0-msix2: PCI-MSI-X enabled: IRQ 58[    7.519987] mpt3sas0-msix3: PCI-MSI-X enabled: IRQ 59[    7.519988] mpt3sas0: iomem(0x00000000b3040000), mapped(0xffffc90010200000), size(65536)[    7.519989] mpt3sas0: ioport(0x0000000000006000), size(256)[    7.595854] mpt3sas0: IOC Number : 0[    7.631852] 64bit 0000:01:00.0 uses identity mapping[    7.658980] mpt3sas0: Allocated physical memory: size(16059 kB)[    7.658981] mpt3sas0: Current Controller Queue Depth(8467), Max Controller Queue Depth(8704)[    7.658982] mpt3sas0: Scatter Gather Elements per IO(128)[    7.718255] mpt3sas0: LSISAS3008: FWVersion(12.00.00.00), ChipRevision(0x02), BiosVersion(08.15.00.00)[    7.718256] mpt3sas0: Protocol=(Initiator,Target), Capabilities=(TLR,EEDP,Snapshot Buffer,Diag Trace Buffer,Task Set Full,NCQ)[    7.718289] mpt3sas0: : host protection capabilities enabled  DIF1 DIF2 DIF3[    7.718291] mpt3sas0: sending port enable !!...snip....[   24.467733] mpt3sas0: _config_request: timeout[   24.467735] mf:[   24.467735]     04000000 00100000 00000000 00000000 00000000 0f000005 00000000 d3000000[   24.467735]     ffffffff ffffffff 00000000[   24.467741] mpt3sas0: fault_state(0x26b5)![   24.467742] mpt3sas0: sending diag reset !![   25.367429] mpt3sas0: diag reset: SUCCESS[   25.367620] mpt3sas0: failure at /root/daily_build/4.2.2/NasDriver/drivers/mpt3sas-8.00.00.00/mpt3sas_scsih.c:5948/_scsih_sas_host_add()![   25.377415] mpt3sas0: port enable: FAILED with (ioc_status=0x00000004)....snip....[  210.600356] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=1)[  211.600994] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=2)[  212.601633] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=3)[  213.602279] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=4)[  214.602908] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=5)[  215.603547] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=6)[  216.604183] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=7)[  217.604829] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=8)[  218.605432] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=9)[  219.606096] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=10)[  219.606098] mpt3sas0: _ctl_do_mpt_command: failed due to ioc not operational[  220.606735] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=1)[  221.607371] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=2)[  222.608015] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=3)[  223.608648] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=4)[  224.609283] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=5)[  225.609923] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=6)[  226.610559] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=7)[  227.611199] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=8)[  228.611834] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=9)[  229.612474] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=10)[  229.612476] mpt3sas0: _ctl_do_mpt_command: failed due to ioc not operational[  230.613110] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=1)[  231.613748] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=2)[  232.614385] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=3)[  233.615022] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=4)[  234.615660] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=5)[  235.616284] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=6)[  236.616936] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=7)[  237.617572] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=8)[  238.618210] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=9)[  239.618848] mpt3sas0: _ctl_do_mpt_command: waiting for operational state(count=10)[  239.618850] mpt3sas0: _ctl_do_mpt_command: failed due to ioc not operational

Also bleibt nur noch der Controller bzw. beide REXP als Fehler übrig....

Mir ist noch aufgefallen das bei dem neuen Server, welchen ich wie oben beschrieben von der Firmware 4.2.2. auf die Firmware 4.2.5.
upgegradet habe, beim booten wird jedoch der Treiber der alten Firmware vom Flashspeicher (DoM) geladen, wie man hier erkennen kann:

[   25.367620] mpt3sas0: failure at /root/daily_build/4.2.2/NasDriver/drivers/mpt3sas-8.00.00.00/mpt3sas_scsih.c:5948/_scsih_sas_host_add()!

Ich nehme an das der Flashspeicher (DoM) sich tatsächlich erst aktualisiert, wenn der Server mit der "neuen" 4.2.5 Firmware gebootet hat und dann auf Werkseinstellung gesetzt wird oder wirklich erst nachdem man ein Firmware Recovery ausgeführt hat. Da der neue Server nie die Firmware 4.3.x gesehen hat wird es wohl auch nicht daran liegen das der Fehler nach wie vor präsent ist.

Ich habe übrigens mit der Hilfe QNAP Sales Deutschland geschafft, das mir ein SAS-Controller aus der Niederländischen QNAP Zentrale zugesendet wird, der dann hoffentlich Anfang der nächsten Woche eintrifft. Der QNAP Vertriebler bei meinen Großhändler konnte mir ebenfalls noch einen SAS-Controller vermitteln. Vielen Dank an der Stelle!!! Mit etwas Glück läuft das Setup Anfang nächster Woche wieder, wenn die Controller & REXP da sind.

Aktueller Stand:
- Neuer Server kommt morgen (QNAP TVS-871U-RP i5 8G)
- Die Lieferzeiten für die anderen Artikel hatte Ezekiel666 schon gepostet

Der Qnap Support (Entwickler) wollten heute noch Seriennummer & Mainboard Version der REXP1620 haben sowie einen IOtest des Expanders (Controller).
- Die Seriennummer findet man auf dem Aufkleber auf der Rückseite der REXP.
- Um die Mainboard Version zu finden muss man die REXP SAS Stecker & Kaltgerätestecker entfernen dann auf der Rückseite 2 Rändelschrauben lösen und dann das Mainboard nach hinten raus ziehen, die Nummer befindet sich dann von oben auf die REXp / Mainboard geschaut unten links.
- IOtest des Expanders, interessant dachte ich mir, was da wohl bei raus kommt könnte...

wget http://download.qnap.com/Storage/tsd/utility/qck
chmod +x ./qck 
./qck all


qcli_storage -d > report
./qck all >> report 
iostat -x 1

Der IOtest brachte natürlich wie zu erwarten keine neuen Erkenntnisse, da der Server die 2x REXP1620 nach wie vor nicht kennt und somit
ein IOtest zu nichts bringt...aber naja.

Also kann ich nur hoffen das es ein Softwarefehler ist, denn...
...morgen kommt der neue Server - im Idealfall war es das!?!
...der Controller kommt als letztes (31.05. frühestens)
...hab ich das Gefühl das der Controller da ist bevor die Entwickler/Support einen konkreten Fehler gefunden haben.

Neuer Server + SAS Controller + REXP sind bestellt, die beiden zuletzt genannten sind jedoch erst ab Mittwoch wieder auf Lager

Der ASR ist für diesen Server & den jetzt bestellten nicht verfügbar, für REXP1620 schon - aber die ist noch ganz denke ich zumindest.
https://www.qnap.com/service/5-year-warranty-ar/en/index.php

SAS Controller + 2x REXP1620 sind kein halbes Jahr alt, wenn etwas davon kaputt ist wäre das auch ne kurze Lebensdauer. Redundante Auslegung baue ich jetzt, jedoch nur bedingt, da die iMac s via 10Gbe LWL darauf zugreifen und das Setup dann zumindest kurz umgebaut werden müsste - aber immerhin besser als gar nicht darauf zugreifen zu können und nicht zu wissen warum.

QNAP Support hat das Problem jetzt an die Entwickler weitergeleitet/eskaliert.

Es wurmt mich auch nicht genau zu Wissen was der Fehler ist und ich da Support seitig keine Infos erhalte, ich überlege schon ich auch noch eine REXP1620 mitzubestellen um das als Fehlerquelle auch noch definitiv auszuschließen. Ich werde sehr stark überlegen ob ich für das Enterprise Segment weiterhin auf Qnap Technik setzen möchte. Der Produktive Ausfall der zeitliche Aufwand des Troubleshootings und die Kosten für die Neugeräte ist nicht gerade unerheblich.

Mal schauen was der Montag bringt...

Ich hab jetzt Deine Variante auch erprobt, leider mit dem gleichen Ergebnis nach wie vor, der Fehler besteht noch.

Also kann es ja nur noch so sein das...

A) der Treiber für den SAS-Controller sich im DoM befindet einen Fehler hat und durch o.g. Verfahren auch nicht zurückgesetzt wird, denn es hat ja bis zum Tag X wunderbar funktioniert.

B) der SAS-Controller einen Defekt hat, einzige weitere Option wäre das beide REXP einen Weg haben, dagegen spricht aber das der LED Indicator keine Fehler anzeigt und beide auf gleichzeitig kaputtgegangen wären.

Also am Montag beim Großhändler via Express einen neuen Controller + NAS kaufen um dann endlich wieder im Normalzustand zu sein.

Weitere Vorschläge zum Troubleshooting sind weiterhin willkommen, bis hierhin schonmal vielen Dank Ezekiel666 für Deine Postings, auch wenn die Kiste immer noch nicht will.

Ich dachte das hätte ich schon?! Ich glaub da musst mir nochmal auf die Sprünge helfen, ich steh grad auf dem Schlauch

1) Habe ich gemacht
2) Dann hab ich hier was falsch gemacht - Wie sorge ich dafür das auch das DoM auf Factory zurückgesetz wird? Ich bin wie folgt vorgegangen: System gestartet ohne jegliche HDD & REXP -> nachdem der Server gebootet hat frische Platte rein -> System auf Werkseinstellung zurücksetzen ausgewählt, Server startet neu.
3) Ich dachte der Schritt wäre in 2) enthalten?
4) Habe ich nicht gemacht.

Dann werde ich das mal testen (müssen). Bin gerade dabei mit einer frischen Platte (alle anderen 3cm gezogen) das NAS auf Werkseinstellung zurückzusetzen um zu sehen ob es dann hoffentlich wieder die REXP erkennt, falls das scheitert bin ich mit meinen Latein am Ende und werde am Montag schnellstmöglich neue Hardware besorgen müssen. Ich hab noch ein Funken Hoffnung das ich es irgendwie hinbekomme am WE.

EDIT:
Hat auch nicht geholfen, Fehler besteht nach wie vor. Bleibt nur noch Server ausbauen & SAS-Controller Slot wechseln. Weiß jemand wie ich testen kann ob der SAS-Controller wirklich noch funktioniert - mittlerweile hab ich fast das Gefühl das Ding ist doch kaputt. Ich konnte bisher auch nicht in Erfahrung bringen was die Fehler von mpt3sas mir im Detail sagen wollen.

Btw. Das NAS dient als 4K Filmdaten Projekt Schnittserver 100TB waren Voraussetzung. 2 iMacs sind via Thunderbolt2SFP+ 10GBe über LWL direkt mit dem Server verbunden und greifen via NFS zu, da FinalCut SMB & AFP Freigaben nicht mag und iSCSI bei 2 Clients keine Option ist.

EDIT2:
Den PCIe Slot tauschen des SAS-Controllers hat auch nicht zum erfolg geführt, Fehler besteht weiterhin. Was ich aber nach "Werkseinstellung" und gezogenen Platten des ursprünglichen Setups nicht mehr verstehe sind die immernoch persistenten Daten aus dem ursprünglichen Setup wie z.B. Systemlogs. Dort kann ich noch Einträge aus 2016 sehen!? Wenn das so ist, wie kann ich der NAS beibringen auch den DoM auf Factory Settings zurückzusetzen damit dann vielleicht sich auch was mit dem SAS-Controller tut? I don`t get it...