Beiträge von Herc

Das Einschränken der Funktionalität von Drittanbieter NVME Adaptern ist leider die ärgerliche Geschäftspraxis von QNAP

Ich hatte es mit einer Fremdkarte (ICY BOX IB-PCI214M2-HSL) versucht. Die wird auch im System erkannt aber lässt sich in der Software nur als Cache verwenden (Und das ist mit meinem TS-253Be und meiner Nutzung unnötig). Die Karte ging dann zurück und ich hab (zähneknirschend) eine QM2-2P-244A gekauft.

Damit QNAPs Karte zwei NVMe Slots unterstützt ist eine PCIe Bridge verbaut, das ist sicherlich mit ein Grund für den hohen Preis. Außerdem vermutlich ein Mikrokontroller, der per I2C mit dem System kommuniziert (Kernelmodul qm2_i2c).

Die NVMe SSD für das System zu verwenden war auch mein Plan: System frisch nur mit SSD booten, einrichten, HDDs rein, Speicherpool nur auf HDDs anlegen. Alle QNAP "Apps" liegen auf der SSD und auch die Daten meiner aktiv genutzten Docker Container. Länger im Standby bleiben die HDDs trotzdem nicht... Vielleicht liegt das an Zugriffen auf das RAID Volume, das QNAP über sämtliche Speichergeräte im System anlegt (bei mir /dev/md13 eingehängt in /mnt/ext).

Ich hab in meinem TS-253Be zwei Corsair 8GB (CMSO8GX3M1C1600C11) und die laufen gut.

Ja, meine Sorge ist, dass QNAP aktiv erzwingt, dass der Port nur mit ihren QM2* Karten verwendet wird.

Zitat von RedDiabolo

Zu 3) es sind sowohl bei den M.2 SATA als auch bei den NVMe Karten eigene Controller notwendig, Von daher sind die Adapter preislich gleich ...

Bei NVMe sollte kein Controller notwendig sein, denn NVMe SSDs sind schon PCIe-Geräte. Wenn meine Behauptung stimmt, dann solltest du im laufenden System nirgendwo etwas von Delock/dem Adapter sehen können.

Diese Delock Karte (89370) als Beispiel ist also eher ein "Konverter", man sieht auf der Platine wie Leiterbahnen direkt von der M.2 Buchse zum PCIe Anschluss gehen:

https://www.delock.com/produkte/G_89370/merkmale.html

Aber was QNAP jetzt tun könnte ist den PCIe Port zu deaktivieren wenn keine QM2* drin steckt oder nur wenn eine QM2* Karte erkannt wird den (generischen) NVMe Treiber laden.

PS: Eine SATA SSD braucht definitiv einen Controller zwischen SATA- und PCIe-Protokoll.

Hallo,

Ich möchte in mein TS-253Be eine M.2 SSD per PCIe Adapter einzubauen und als zusätzlichen Speicherplatz nutzen.

Hat jemand Erfahrung mit der Kompatibilität von günstigen PCIe/NVMe M.2 Adapterkarten von Drittanbietern?

Ich habe von Qnap diese Seite gefunden: https://www.qnap.com/de-de/how…-nvme-pcie-ssds-verwenden

Dort heißt es wegen "Kompatibilitätsproblemen" mit unterschiedlichen Marken von NVMe-Solid-State-Laufwerken (SSDs) kann man NVMe SSDs auf Karten von Drittanbietern nicht mehr als Speicherplatz verwenden.

1) Eine kompatible SSD lässt sich ja finden, aber mir geht es um den Adapter.

2) Eine NVMe SSD ist ja schon PCIe, ich nehme an ein Adapter ist dann (mehr oder weniger) passiv. (Für eine einzelne SSD ohne PCIe Switch)

3) Ob M.2 per NVMe oder SATA ist bei meinem NAS nicht so entscheidend, aber die Adapter sind für NVMe deutlich günstiger (da kein Controller).

Zitat von "dosenhuhn"

Mit Lokal meinte ich auf dem iPhone an sich.

Und genau das geht mit der Remote App auch garnicht, denn die App ist nichts weiter als eine Fernbedienung. Du kannst damit dem QiTunesAir sagen zu welchem AirPlay Client (Apple TV, Airport Express oder PC Programme wie shairport4w etc.) er streamen soll.

Zitat von "dosenhuhn"

Aber wie geschrieben konnte ich Lokal keine Musik abspielen

Was ist für dich "lokal"? Die Remote App auf iPhone/iPad ist grundsätzlich nicht in der Lage selber etwas abzuspielen. Der forked-daapd (die "Intelligenz" hinter QiTunesAir) kann das prinzipiell zwar, aber ich denke Qnap hat eine Ausgabe auf dem NAS selbst durch QiTunesAir nicht vorgesehen.

Zitat von "hoddelac"

... So hat es bei mir zumindest funkioniert.

Also läuft nun alles bei dir?

Zitat von "outside"

nuß der Rechner mit iTUnes auf jeden Fall an sein?

Du brauchst prinzipiell garkeinen Rechner mit iTunes mehr. Um deinen Rechner für die Wiedergabe zu verwenden kannst du http://sourceforge.net/projects/shairport4w/ installieren und dann per iPhone/iPad das QiTunesAir an den Rechner streamen lassen.

• Hast du die Konfigurationsdatei vom forked-daapd geändert? (darauf setzt QiTunesAir auf)
• Wurden die *.remote Dateien von der QiTunesAir Weboberfläche korrekt angelegt?
• Kommst du mit SSH klar? Dann führe auf dem NAS mal
  
  Code

  # avahi-browse -a

  aus, das zeigt alle per avahi/bonjour angebotenen Dienste im Netzwerk und poste hier die Ausgabe

Problem gelöst!
Ich hatte das Verzeichnis in dem der forked-daapd nach Musik suchen darf geändert, die *.remote Dateien lagen aber natürlich weiterhin in /share/Qmultimedia/. Sobald ich die *.remote Dateien verschoben habe, klappte auch das Pairing mit iPhone und iPad.

Hat jemand das QiTunesAir QPKG erfolgreich laufen?
iTunes erkennt das NAS als Freigabe und streamed auch Musik. Das Anlegen der *.remote Dateien über das Webinterface des QPKG klappte auch, aber iPhone und iPad wollen das NAS in der Remote app nicht hinzufügen.
Hat jemand dazu eine Idee? Fehlt mir was?

Ich habe die Frage auch im qnap.com Forum gestellt. Die Antworten synchronisiere ich natürlich - nicht das ich hier Ärger mit dem Platzwart bekomme!

Die aktuelle Firmware 3.5.0 unterstützt "Service Binding" / "Dienstbindung" (siehe http://www.qnap.com/de/fw_v35/servbiding.asp) und deine beiden NAS-Systeme haben zwei Netzwerkkarten, sollte das nicht für deine Anforderungen reichen?

Und außerdem hast du doch sicher sowieso noch einen Router/Firewall vor "dem Internet"? Sollte dein Router kompromittiert werden hast du sowieso verloren.

In random order... 8-)

• native CalDAV and CardDAV (or adressbook-ready LDAP Server) (Maybe SoGo? DAViCal?)
• StandBy-Support
• more intelligence for the poweroff schedule (ping specific IPs, look for open connections)
• integration of debian/ubuntu APT repository
• native TFTP/PXE Boot Server
• Mapping of remote shares to local shares (AVM Fritz!Box does something like that with WebDAV and caching on a local USB key)

Ich hab von meinem TS-239 Pro NAS das /dev/sdx Device gedumped und eine virtuelle Festplatte draus gemacht (VMDK):

• Der Grub ist im MBR
• sdx1: Grub config
• sdx2 und sdx3: redundant Kernel, Ramdisk und RootFS
• sdx4: kA (kann Dateisystem nicht mounten)
• sdx5: leer
• sdx6: enthält die Konfiguration (uLinux.conf, etc)

Der Kernel bootet grundsätzlich (bei mir in VMware Fusion und VirtualBox), allerdings wirft er einige Fehler beim Laden vom RootFS. Wenn er "Extract RootFS Ext..." versucht, kommt: "mount: /dev/sdx2 is not a valid block device". Danach gibt es diverse Fehler beim Laden von shared object Files von daemon_mgr und getcfg. Anschließend hängt er bei irgendwas aber mit Strg+C erscheint der normale login wo man mit admin:admin rein kommt.
Irgendwie erkennt er die Festplatte von der er gebootet hat nicht richtig, unter /sys/block/ sehe ich nur ein sdX Device: "sdiv". Unter /dev/ gibt es dafür keine Einträge und ich kann es somit nicht mounten. Die uLinux.conf habe ich durch die Default-Version ersetzt aber das ändert nichts.

Mein Problem ist also: Wie mounte ich das RootFS?

In der uLinux.conf gibt es "System Device = /dev/sdx", sollte das sich das RootFS also irgendwie mounten lassen, sollte sich vielleicht da der Pfad anpassen lassen.

Die Qnap Firmware zu virtualisieren würde mich auch reizen.

Gibt es eine Möglichkeit direkt die Firmware Images auszupacken?
Ich habe versucht die unter Linux einfach zu mounten, aber das hat mit keinem Dateisystemen geklappt. Da der Inhalt einer Firmware *.img Datei einen sehr unregelmäßigen Eindruck macht und sich auch durch Zippen nicht komprimieren lässt, wird der Inhalt wohl bereits komprimiert, bzw. gar verschlüsselt sein. Weiß da jemand mehr? Habt ihr auf dem NAS die Firmware-Update-Routine finden können?

Den anderen Ansatz, den Inhalt des FlashModuls von einem laufenden NAS zu extrahieren, werde ich demnächst mal versuchen. Hat das schonmal jemand gemacht?

Damit das hier mal konkreter wird, es muss unterschieden werden zwischen Dateisystem und Protokoll. Dabei sind SMB (=Samba/CIFS) und AFP Protokolle für Dateifreigabedienste und HFS, NTFS, FAT, EXT?, usw. Dateisysteme.

Wenn es jetzt um einen Remote-Zugriff geht, dann ist für den Client das Protokoll entscheidend: Mac OS unterstützt sowohl SMB als auch AFP, Windows nur SMB. Über diese Protokolle stellt der Server (das NAS) eine Freigabe zur Verfügung deren Inhalt in einem Dateisystem liegt. Grundsätzlich ist es also für den Client völlig transparent welches Dateisystem der Server benutzt denn er benutzt ausschließlich das Protokoll.

Nun gibt es in den Dateisystemen aber noch Dinge wie "Extended Attributes", also (bildlich) sowas wie Zusatzinformationen zu den vorhandenen Dateien. An dieser stelle könntes es möglicherweise Probleme geben wenn eine Software soetwas benötigt. Dass das bei Aperture oder iPhoto der Fall ist mir weder bekannt noch kann ich mir das vorstellen.

Bei iSCSI sieht das ganze anders aus, denn dabei hast du eine "virtuelle Festplatte" in deinem Client, die du dort behandeln kannst wie eine normale Festplatte. Das heißt du kannst die mit einem bliebigen Dateisystem formatieren, unabhängig ob der Server das kennt oder nicht. Trotzdem liegen die eigentlichen Daten auf dem Server und werden über das iSCSI-Protokoll übertragen. Du kannst dir das bildlich so vorstellen als hättest du eine (virtuelle) Festplatte in deinem Server mit einem langen Kabel mit deinem Client verbunden.
Auch wenn das gut klingt ist das für eine "Dateifreigabe" eher nicht geeignet denn keines der gänigen Dateisysteme ist dafür geeignet von mehreren Benutzern gleichzeitig verwendet zu werden.

Zur Geschwindigkeit: Über Gigabit bekommst du theoretisch über 100 MB/s, somit ist die Netzwerkverbindung erstmal kein Nadelöhr. Anders sieht es mit der Latenz aus, die ist natürlich höher als bei direkt im Client verbauter Festplatten, aber ob das für iPhoto/Aperture ein Problem ist weiß ich nicht.

Sollte es Programme geben die partout ein HFS+ Dateisystem (und keine Freigabe, mit welchem Protokoll auch immer) benötigen, dann bleibt dir immernoch iSCSI. Damit ist es möglich eine "virtuelle Festplatte" in dein Mac OS einzuhängen die vom System wie ein "Gerät" behandelt wird.

Das ist schon klar. Das eigentliche Aufwachen war auch weniger das Problem, sondern eher, dass das alles automatisch abläuft.

Mich würde eher noch interessieren, dass Qnap das automatische Herunterfahren mal etwas brauchbarer umsetzt. So wird nur gecheckt ob gerade ein Backup läuft, es können aber ja noch eine Reihe mehr Verbindungen offen sein. (iSCSI, SSH, SMB, AFP, usw)

Leider ist der forked-daapd noch zu sehr Beta als das es sich lohnen würde den zu portieren. Hatte den nochmal aus den Sourcen kompiliert, aber die ganzen Abhänigkeiten auf das NAS zu bringen tue ich mir nicht an... Außer mir kann jemand sagen wie sich das alles statisch einkompilieren lässt

Macht sonst aber einen guten Eindruck der forked-daapd. Sogar Videos lassen sich problemlos streamen, mit dem mtdaapd war das ja ein Krampf... Das Verbinden mit der Remote.app auf dem iPhone klappt zwar und er zeigt die Dateien an, weiter konnte ich aber leider nichts damit tun.

Mal abwarten was von Qnap kommt...

Ich hab den forked-daapd schonmal in einer VM zum Laufen gebracht, macht einen netten Eindruck und funktionierte meine ich auch mit iTunes 10. Die Abhängigkeiten sind etwas haarig.. Soll Qnap mal selber ordentlich machen, hab keine Lust da mit den ipkg was zu fummeln

WOL über das Internet klappt bei mir nicht, weiß auch nicht ob es an Router, App oder NAS liegt