Beiträge von bucherst

Moin alerseits nach langer Stille. sorry meine Studienarbeiten rufen

Evt noch meinen Senf zum Tema Cache. Gibt es ja als lese, schreib oder lese-schreib cache im QTS. QES und QTSHero nur als Lese Cache wegen ZFS struktur und daher total anderst.

Warum führt es in der Praxis auch zum Datenverlust im QTS? Mögliche Lösung und Ursache ist folgende:

Wie wird dein Cache angelegt?
Der Cache wird über eine eigenständige Disk oder Raidverbund angelegt und bindet sich in dein Dateisystem ein. Im optimalsten fall, hat der zur Verfügung stehende Superblock natürlich einen hohen Duchsatz (Bandbreite/IOPS) durch gute Disks und/oder dedizierte Schnitstellen. Daraus natürlich die abgeleiteten Rechte: Schreiben, lesen oder beides

Warum geht dein Cache überhaupt kaput ? Dein QTS entscheidet selbst, wenn du den Cache "ON" hast ob er eine Datei XY in den Cache legt. Daher weiss nur dein ex4 Dateisystem auf dem QTS aufgebaut ist welcher superblock Berreich für "Cache" ist und welcher für "Data" zur Verfügung steht.
Logischerweise stellt es dein Dateisystem für das du gerne Cache haben willst unter Dauerstress, und zwingt es im iNode register des Dateisystems die Register umzuflaggen, wenn jetzt eine Datei in "Cache" oder in "Data" verlegt wird und erzeugt somit viel Leistung.

Daher ist auch ZFS viel effizienter da das ZIL in das Ram geladen wird und wie eine Datenbank lesend abhandelt. Daher auch bei Benchmarks ZFS viel effizienter im lesen aber schwächer als ext4 im schreiben. Da vermutlich heutzutage die meisten 70-80% lesevorgänge haben eine gutze Wahl aber eben das ist wie Äpfel mit Birnen zu vergleichen....

nun zurück zum möglichen Crash Szenario:
Da deine Volume die du erzeugst "Virtuele gebunden Verzeichnisse im QTS sind" die sich über X Raids und Volumes hinwegziehen geht logischerweise beim Ausfall des einen oder anderen physischen Volumen oder gleich dem Raid das Virtuelle gebilde flöten. Daher Datenverlust und Systemcrash...!
Ich bin aber mit der Aussage einig, dass wenn noch ein superblock eines Raids intakt ist ein Recovery einer Datei aus dem caches möglich ist.

Es ist leider nicht immer alles stabil was Dynamisch/virtuell erstellt wird. Ich persöndlich empfehle auch eher QTier zu verwenden, da es besser Einstellbar ist und die oberste Ebene (Raid/superblock) eher der treibende Trigger ist, dass birgt weniger Risiken im iNode Register vom ext4 Dateisystem aber ist natürlich hier auch der gleiche Crash möglich.

Cache ist eher dazu gedacht die Schreib- Lese Latenzzeit von ext4 zu verkürzen (Gap zwischen dem Ext4 Dateisystem zum Server Memory, CPU und der Weitergabe an Periferie) und gerade bei IOPS lastigen Anwendungen wie bei Datenbanken und Streaming ein Gamechanger.

Zitat von jogovogo

Weisst du wie viel Overhead ca. bei iscsi generiert wird gegenüber einem NFS Share?

Müsste bei software ISCSI gleich sein. MTU 1500 ergeben ca. 1460 Bit Transport PDU pro session. Bei Software iSCSI hast du sicher einen schnelleren Session aufbau wenn du mit Mutipath und mindestens 2 Kernel ports arbeitest ist die Übertragung schneller und stabiler. Bei NFS könnte es dir in die Hände spielen wenn du NFS v4 mit RDMA einsetzt, da die Voraussetzungen für die Netzwerkinfrastruktur kleiner ist und mehr CPU Power für die VM`s zur verfügung steht, jedoch verzichtest du dann auf die RAW Disk was bei Hostcache configuration auch nochmalls eine Rolle spielt. Da du auf dem dell Server einen Hardware raidcontroller hast würde ich an deiner stelle mit Host cache und iSCSI Lun arbeiten und die beiden ESXi host mit dem vCENTER pairen, so kannst im Fehlerfall eines Hosts auch gleich nahtlos switchen und die XEON hat ja ordentlich power um Software iSCSI wegzustecken.

Zitat von jogovogo

die TS-977XU-RP liegt preislich vierfach, die Frage ist ob sich das lohnt...

Deine Entscheidung. Der Vorteill gerade bei iSCSI liegt darin, dass du die LUN als RAW Disk gleich dem client zuweisen kannst. Bei zwei ESXi Server kannst du so nahtlos im Fehlerfall zwischen den ESX Hosts switchen. Bei Hardware Acelleration (iser) hast du natürlich nochmalls ca 40-60% mehr performance, bedinngt aber, dass du eine RDMA fähige infrastruktur hast.

Übrigends falls du dich für iSCSI entscheidest lohnt es sich mehrere iSCSI kernel Ports zu öffnen. Pro ESX Host würde ich aus performance und Redundanz gründen gleich vier generieren und die 10GB/s ports auch gleich als Multipath hinzugeben, soo hast du ordentlich Leistung

Ich würde eher auf eine: TS-977XU-RP setzen, diese am ESXi Host mit Mellanox karten per iSCSI RDMA anbinden und den ESXi host cache verwenden. Falls du bei diesem Gerät auf Caching setzt, würde ich es eher als QTier in einem solchen fall einsetzten. Was hat der Dell server für eine Power?

Beim TS-435XeU würde ich es als NFS konfigurieren, da Software iSCSI ordentlich CPU Power benötigt und die Mve als cache verwenden.

Ich denke der Switch von FS lässt sich sicher per ssh ansprechen. Hast du dort schonmal geschaut was der Port im Detail sagt auf den du das DAC einsteckst?

Mit DAC Kabeln von FS habe ich eigentlich nur gute erfahrungen gemacht, gerade wenn du die "Generic" kaufst ist die Unterstützung sehr breit

Ich habe aus eigeninteresse schon diverse Apple OSX auf VM`s aufgebaut oder ein paar Hackingtosh hergestellt und damit experimentiert. Es gibt hier ein paar Schritte/Stolperfallen die man beachten muss, aber grundsätzlich mit jeder x86 kompatiblen Apple hardware möglich ist. Egal ob jetzt physisch oder virtuell oder in einer Paravirtualisierungsform, dass Muster ist immer das gleiche im vorgehen:

1. Apple Betriebssystem runterladen und /oder ISO/USB erstellen (Dazu findet man im Netz sehr viele Anleitungen)

2. (Hier kommt der HUND und warum es auch bei QNAP nicht einfach so geht aber möglich wäre); Wie bei der Virtualisierung oder auch beim physischen Hackingtosh ist das Ofset der Register wichtig. Ohne dem keine Chance...

Oftmalls sind bei VM`s die advanced Sachen im BIOS weg oder es fehlt schlicht die Hardware Offsets für die Register die das OSX benötigt um Hardware Physisch/virtuell anzusprechen. Für die, sich gerne mit Python auseinander setzen ist unloker 3.0.8 für esxi auf dem Github als frei zugänglichen Code verfügbar und sehr kurz geschrieben was sie Ofsets betrifft. Ich denke wenn jemand Erfahrung im Register lesen hat, wird sich eine VM auf Windows oder Linux kurz aufsetzen die Register auslesen und dementsprechend richtig für sein "apple" Offsetten und das gewählte Muster selber patchen.

Nebenbei: Die von Clover oder Opencore EFI auf der Physischen seite verfolgen dasselbe prinzip, daher:

Wenn ich hier meinen Senf dazu geben will am besten macht er sich schlau was es schon gibt an kompatibler Apple Hardware indem er entweder die Apple page selber besucht oder in den Hackingtoshforen nach Apple kompatibler Hardware sucht, die sich simulieren lässt und unter umständen Ofset werte bekommt.

So als Tipp die es gerne auf der QNAP versuchen möchten:

Ich kann mir auch gut vorstellen das sich die VM von QNAP auch ohne patchen aushebeln lässt indem man eine vm als Linux erstellt wegen dem CSM und dann mit opencore EFI und den benötigten ofsets daherkommt um die ofset register hinzubekommen. Es wäre dann ein bischen Kosmetik die Linux beschriftung in ein Apple umzuschreiben.

Mit minimal settings hier zu arbeiten ist unter umständen mehr als es gleich von vorhinein komplex zu machen. also deshalb am anfang noch auf USB und allen schnikschnack verzichten.

3. EFI Schicht vorbereiten/Idividualiseren. Aus meiner Sicht haben die Jungs von open core aktuell die Nase am weitestens vorne. EFI Clover ist meines erachtens auch immer noch möglich und für die wilden das Project vanilla. Alles findet man hier dazuals offenen Code im Github oder auch in den Hackingtosh foren. Tipp beim Booten (verbose mode einschalten, dann sieht ihr auch in welchem register er stecken bleibt und was zu fixen ist)

4. OSX Installieren, genau glich wie bei einem Apple Gerät

5. Jenachdem noch Treiber anpassen oder etwas Kosmetik

Kurzum, meines erachtens wäre das Spiel auch auf der QNAP möglich, aber wie schon in den Post oben beschrieben gibt es bei Hostern und RZ Anbieter schon Macs zum Mieten mit neuster M1 CPU technik, da würde ich mir den Stress nicht machen um eine VM herzustellen sondern gemütlich VNC Tunnel benutzen und gut ist.

Zudem muss ich sagen da ich mal damit experimentiert habe es stressig ist auf jede veränderung zu reagieren un es nicht zwingend weiterempfehle sofern es nicht experimental ist. Gerade auf die OSX Major updates machen viel Probleme. Da benutze ich lieber was Apple Originales und gut ist.

Zitat von Aladrin

Oder eine Cloud Lösung doch besser?

Pro:

- Je nach Datentyp und gewählter Cloud gleich Hybridcloud fähig

- Backup ausser hause

Negativ:

- Laufende Kosten

- Braucht etwas Performance (Netzwerk/Internet)

- für mind. 4TB brauchst du oft ein Business Abo; Bsp: Dropbox Business Standard mit 5TB

Zitat von Aladrin

Oder eine Externe HDD kaufen und diese anschliessen?

Pro:

- einmalige Investition

- Snapshot lokal

Negativ:

- Kann auch kaput gehen

Wenn du dich für eine lokale Disks entscheidest würde ich an deiner Stelle auch gleich eine Grössere nehmen. 10 - 16TB so kannst du auch verschiedene Snapshoots beibehalten

Zitat von Aladrin

Habe noch Festplatten bei meinem PC frei!

Mit Qsync oder einem Backupprogramm zu arbeiten sicher auch keine schlechte Iddee, jedoch muss für das Backup dein PC an sein, ich würde da eher eine externe Harddisk über USB bevorzugen.

Hallo sofern du mit SSH bewannt bist liefere uns doch mal folgende information über den Raidzusand sowie ein paar Diskinformationen.

1. So verbindest du dich mit ssh: ssh DEIN-BENUTZER@DEINE-IPAdresse -> Passwort eingeben

2. Achte darauf ob du "#" prompt am ende deiner Eingabe hast, ansonnsten: sudo -s -> Passwort eingeben

Sende anschliessend folgende Befehle ab und stelle sie mal hier hin:

cat /proc/mdstat
qcli_storage -d
cd /
df -h

Gutmöglich das es sich auch um das neuste Firmware update handelt.

Gleiches Problem bei mir, Firmware gestern bei einem Gerät durchgeführt heute morgen die gleiche Meldung

Welchen release hast du drin und welche Karte?

Bei mir:
OS: QTS 5.0.0.1932 build 20220129

Bosterkarte: QM2-4P-384

Disk: 4 X Samsung 970 Pro 1TB // Ausfall einer Disk, die restlichen haben eine Performance von lächerlichen 550MB/s statt 3GB/s

Interessanterweise:

Bosterkarte: QM2-2P-384 mit 2 X Samsung 970 Pro 1TB keine Probleme auf dem gleichen Gerät

qcli_storage -d

wäre noch gut zu wissen ob es die disks überhaupt noch gibt

Zitat von Crazyhorse

Ich spreche hier von Praxiswerten die meine Exos im Echtbetrieb liefern und das ist mindestens 150MB/s auf der letzten Rille wenn das Raid Scup 1 mal im Monat läu

Oh wow Ich habe gerade mit exos x16 16TB SAS modellen ein Scrubbing am lauffen. 195MB/s zeigt es bei mir. Könnte aber auch daran liegen das SAS und SATA da nochmalls einen Unterschied ausmachen.

Ich weiss nicht ob dies wie bei den Synogeräten einen Unterschied ausmacht, aber hast du eine Möglichkeit den Boot mode deiner VM von BIOS auf EFI zu stellen. Anderen Grund könnte vielleicht auch noch sein, dass wie bei ESxi die gewünschte Perifferie zuerst als Passthought markiert werden muss und erst nach einem Neustart des Servers anwendbar ist.

und schau mal hier:

Die Unterstützung für die GPU Passthrough ist auf Windows-basierte VMs beschränkt und ist nur für bestimmte QNAP NAS Modelle und Grafikkarten verfügbar. Weitere Informationen erhalten Sie unter https://www.qnap.com/go/how-to…in-virtualization-station

also VM Typ als Windowsmachiene defineiren

Zitat von Civer

Sorry, aber für was steht 1G? Meinst du damit 1GB/s und damit dann die Pace des Netzwerkes? Sollte es dann aber nicht auch noch auf die anderen Hardwarekomponenten, sowie ein paar andere Faktoren ankommen?

Ja entschuldige ist meine Art was abzukürzen. Natürlich meine ich damit 1GB/s Netzwerke. Selbstverständlich kommt es da auf ein paar andere Faktoren noch mehr an Ich wollte einigermassen beim Thema bleiben. Wäre sicher auch noch ein spannendes Thema: Welche Netzwerkgeräte sind wirklich gut :-). Ich wurde legidlich darauf hingewiesen oder Zitiert, dass SSD in 1GB/s Umgebungen nichts bringen und bin der Meinung das dies auf Festplatten nur begrenzt stimmt wenn man das IOPS aufkommen in einem 1GB/s Netzwerk berücksichtigt. Solange Qnap keine neuen Geräte mit SAS Storage Controller und Backplane herstellt wird man sich vermutlich gute SSD suchen müssen anstatt auf SAS Disks mit hoher Drehzahl zu setzen um die IOPS Anzahl zu bewerkstelligen.

Mod: Unnötiges Volltext-/Direktzitat entfernt! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

Crazyhorse

150MB/s scheint mir sehr wenig zu sein oder auch die Schwankung, da würde ich beim Hersteller reklamieren. Schau mal das Techsheet von Seagate aus der Exos X16 Serie an: https://www.seagate.com/www-co…DS2011-2-1910DE-de_DE.pdf

Bei der 10TB Disk: Max. kontinuierliche Datenübertragungsrate OD (MB/s) 245, 233

Ob du Random IO hast oder sequenzielle IO auf einer Disk am laufen hast liegt mehr an deinem Dateisystem, dass deine Storageblöcke verwaltet und die Daten darin ablegt.

4Euro für ein gutes Kabel mit anständiger SFTP Kat7 Quallität würde ich als realistisch bezeichnen.

Eine paar andere Frage hätte ich aber dich;

- Du verwendest ein 453D richtig? Laut Benchmark auf der QNAP Page liefert das 543D max 406MB/s lesen und 689MB/s schreiben im 10G Mode. Dies aber auch nur unter der voraussetzung das SSD darin verbaut sind, wie unten in der Benchmarkpage auf der Configuration beschrieben ist. Kann es sein, dass deine NAS Konfiguration wesentlich tiefer liegt als das Maximum und du nicht mal annähernd keine 10G ausreitzen wirst? Wenn du mich fragst ist die Performance bei einem 543D mit 5GB/s berreits schon mit Laborwerten zu 95-98% ausgereitzt, die 10G konfiguration kommt dabei sowieso nie an die maximale Leistung von ca 1150MB/s heran. Die Frage die ich mir stelle ist, ob es sinnvoll ist nochmalls zu investieren und alles 10G tauglich zu machen wie Kabel, etc. auszutauschen anstatt sinvollerweise das Nas mit 5GB/s zu betreiben. Die angegeben Werte sind ja auch nur Laborwerte die unter guten vorasusetzungen zustande kommen. Ich kann mir da auch gut vorstellen, dass in einem regulären Betrieb dein NAS mit 5G berreits schon zu 100% ausgelastet ist.

- Hast du schonmal versucht den Portspeed von Autonegation deiner 10G Karte am Mac auf manuell umzusetzten und mit 5G oder 2.5G zu betreiben. Dies natürlich mit deinem aktuellen Kabel? Es könnte auch ein konflikt darin bestehen, das die Verbindung nicht korrekt ausgehandelt wird.

Wenn du mich Fragst finde ich die Diskusionen über Kat7 etwas überbewertet. Es gibt zwar schon Kat7 Kabel jedoch keine Stecker mit Kat7, daher spielt es bei so kurzen Distanzen keien grosse Rolle ob du jetzt mit 2 Meter Kat7 oder Kat6 fährst. Ich denke egal welche Art von Kat6 oder Kat7 Kabel du verwendest hauptsache es ist gut von Innen nach aussen geschirmt um Störeinflüsse zu reduzieren. Erfahrungsgemäss funktionieren Kat6 oder Kat7 Verbindungen und 10G Berieb bis zu 30-40 Meter auf einem Mac.

Zitat von Crazyhorse

Bringt dir am Client weiterhin nur bedingt etwas, da du die Netzwerklatenz vergisst.

Hier bist du bei Faktor 10 oder sogar 100+ gegenüber der reinen SSD Zugriffszeit.

Das wirkt sich massiv negativ auf die IOs aus.

Ich denke es kommt auf die Anwendug am Client an, mit welchem Protokoll er eingebunden ist und daher auf eine Disk mit hohen IOPS werten angewiesen ist. Halbgefüllte Züge könnten auch mit kleineren Wagons beladen werden, damit sie voll werden, es gilt da sicher eine Sybiose zu schaffen was Sinnn ergibt. Schlussendlich kostet eine SSD das x Fache einer NLE wenn man den Preis pro GB Kalkuliert.

Meiner berechnung nach kommt ein Jumbo IP Paket im optimiertesten Fall und voll gefüllt auf 9000 Bits als Datenpaket daher. Demzufolge müssten pro gelieferten Paket ca 8.5MB Daten enthalten sein das eine Disk in 4KB Speichereinheiten unterteillt und somit = 2176 IOPS benötgt. Darauf könnte man schon schliessen das bei einer NLE Disk mit 200 IOPS und ohne Cache es schon über 10 Stück benötigt um die Speichergrösse eines 9000 Bit grossen Pakets aufzufangen. Zum Glück haben ja auch Festplatten ihren Cache, aber es Zeigt die Problematik, das wenn gössere Dateien auf einer Disk ausgetauscht werden oder die Anzahl an Dateien gross ist der Cache schnell zum überlauffen kommt und die Disk an den Anschlag bringt. Daher hat eine gute Festplatte für mich nicht nur Kapazität sondern auch ein gutes und zuverlässiger Cache verhalten oder vorhinweg einen hohen IOPS Wert was sie direkt leistet. Viele wundern sich ja warum ihr gemessener Benchmark was ganz anderes ist als wenn sie arbeiten und die Bandbreite plötzlich taucht aufgrund ihres Verhaltens.

Gute 1G Netzwerke schaffen ca 116 MB/s. Da ein IO Storageblock 4KB benötigt, wären auf einem 1G Netzwerk ca. 28K-29K IOPS rein rechnerisch möglich, die es mit IOPS Leistung abzudeken gilt. In der Praxis wirst du bei ca. 20K IOPS begenzt, da Netzwerk ihren Overhead hat und auch kolisionen ausgleichen muss oder die Datenpakete sowieso nicht vollständig gefüllt werden. Demgegenüber liefern gute SSD im SAS oder SATA Berreich wie eine Intel DC Serie ca. 72K IOPS etwa Faktor 3-4 mehr in der Theorie, praktisch wirst du vielleicht das 10fache mal schnell darunter legen. Natürlich ist dies ein bischen einen Overkill wenn man 1G Netzwerke betrachtet, ganz zu schweigen von PCIe mve mit 300K IOPS und höher. Man könnte in einem 1G Netzwerk den höheren Disk Tier auch mit NLE mit hoher Drehzahl effizienter gestalten um die maximale IOPS Leistung abzudeken, dies macht sicher auch deine Geldbörse glücklicher und ist genauso effizient.

Um noch 10GB/s Netzwerke anzusprechen. Diese sind da schon wieder eine ganz andere Liga unterwegs mit rechnerisch über 280K IOPS in der Spitze. Werden Festplatten für IOPS intensive Aufgaben wie VM oder ISCSI in 10G Umgebungen benötigt, kommt man um ein SSD Tier Raid mit guten SSD kaum herum um die benötigte IOPS Werte zu erreichen. Praktisch wirst aber auch hier oft im niedrigen berreich liegen und in einem eher ruhigen Zustand zwischen 400-500 MB/s und 20K IOPS im Normalbetrieb liegen wenn es um eine VM Anwendung geht. Über 200K IOPS und mehr Bandbreite wirst du vielleicht am morgen feststellen wenn jeder seinen VDI Client startet oder jemand grosse und viele Daten kopiert/verschiebt die sich gut segemntieren lassen.

Damit sich eine Disk oder Storageverbund nicht verstolpert oder an den Anschlag kommt ist sicher ein Mix von unterschiedlichen Tier Geschindigkeiten in einem System das beste um zwischen Bandbreite / maximaler IOPS und Speichergrösse das beste rauszuholen. Das Anwenderverhalten hat auf eine Disk einen wesentlichen Einfluss, damit sie optimal ausgelastet wird.

Um nicht vom Thema abzuschweifen sollte man bedenken das eine gute Disk nicht nur zuverlässigkeit beweisen soll sondern ausgeglichen in der Leitung, Kapazität, Preis und derem Nutzen eingesetzt werden soll. Ebenso zählt für mich auch die kontinuierliche Austauschbarkeit eines Disknachfolgers im falle eines Fehlers oder Nachfolgeplanung zu den Eigenschaften einer guten Disk.

Eventuell noch andere Iddee wie du es gut zurück bekommst. Ersparrt dir das noch eine Kiste Zusätzlich läuft und der Vorgang geprüfft wird.

1. Hybridmount Einrichten Synology share auf der Qnap mounten

2. QTS einloggen und über den Integrierten Dateibrowser kopieren

Aus meinner sicht besser weill:

A) CRC Checksummen beim kopieren erstellt werden können

B) Der traffic direkter läuft

C) Du keine 3. Kiste benötigst

Zitat von Civer

Aber oft lauten die Meinungen im Netz das SSD eigentlich nicht unbedingt für NAS geeignet sind. Allerdings wird sich hier meist auch nur auf das Preis-Nutzungs-Verhältnis und die damit verbundene Tatsache, dass dieses sehr schnellen Speichermedien in einem NAS "over the top" wären (vergleiche hier: SSD im NAS bezogen.

Naja ich teille diese Aufassung nur Ansatzweise. Vielleicht mag vieles wie im Link herangezogen auf 1G Netzwerke teilleweise zutreffen. Zu bedenken ist, dass SSD viel höhere IOPS werte liefern als Nearline Harddisks. Ich denke es gibt auch im 1G Betrieb einen Unterschied wie das NAS angebunden ist und daher auch die IOPS verarbeitung gut beherschen muss. Heutige gute NL Disk schaffen im Sequenziellen lesen und schreiben etwas die Hälfte eines SATA SSD, daher mag dies bei kleinen Dateien und SMB/AFP/NFS sharing wohl keinen Einfluss haben, wenn Daten sequenziell auf Blöcke geschrieben werden. Ganz anderst sieht es da aber bei zufälligen IOPS aus, dort nimmt die Leitung von NL Disks gegenüber SSD rapide ab. Ich denke aber überall wo ganze DVD Samlungen oder dgl. rungeschoben werden ist man auch in einem 1G Betrieb froh wenn die Disk etwas schneller ist als minimal empfohlen. Dateisysteme haben ja auch noch ihren Einfluss wie der Cache beschleunigt wird, daher sehe ich den Einsatz von SSD in einem NAS auch als sinvoll. Natürlich ist es ein bischen einen Unsinn und etwas einen Overkill bei 1G Betrieb auf PCIe MVE cache zu setzen (nice to have wenn man es hat). Ich denke es würde auch schon reichen einen Cachebooster oder QTier mit SATA Technologie zu betreiben um dem ganzen den Pfeffer zu geben. Wo ich ganz sicher einverstanden bin ist die Aussage, dass die Hauptaufgabe eines NAS darin besteht möglichst grosse Speicherpools allen zur verfügung zu stellen.

Zitat von Anthracite

Für ZFS gilt das aber nicht, da ZFS die Raid-Funktionalitäten selbst mitbringt und das Raid selbst verwaltet. Raid und Dateisystem sind hier als eine Einheit zu sehen. Und das Raid kann nur das, was ZFS unterstützt.

Weisst du gerade ob dies bei allen Raidtypen der Fall ist? Soviel ich weiss bring ZFS den Raidtyp F1, F2 und F3 als eigenen Raid verwaltung Modus mit. Hat hier jemand Erfahrung?

Zitat von Mavalok2

Habe ZFS bei NAS jetzt nicht im Einsatz, aber man liest auch hier, dass es mit der Flexibilität einfach mal eine Fesetplatte so zum RAID hinzufügen vorbei ist. Auch der Speicherpool soll nicht mehr ganz so flexibel sein. Etwas was gerade die privaten Anwender doch sehr schätzen.

ich denke man darf hier zwei Sachen nicht verwechseln/vertauschen. Sicher ist QTS Hero wie auch QES hier etwas mürrischer aber grundgenommen gilt. Raid ist Raid und Filesystem ist Filesystem. Ein Filesystem greift legidlich auf ein Raid als Virtuellen Datenträger zu. Raiderweiterungen sollten/müssen vom gleichen kontroller oder Bussystem erstellt werden, damit eien Erweiterung überhaupt möglich wird. Ich denke hier liegt eher der Hund begraben.

Zitat von PhilExpat

Ich verwende Single Disks, das spart den RAID Overhead - und ist sicherer falls der Controller kaputt geht, denn dann sind beide RAID1 Platten gleich betroffen und platt. Und sag nicht das passiert nicht, ich hatte schon das Vergnügen...

Single Disk und mit HBS3 ein Backup oder Sync von Platte 1 auf Platte 2 machen - so hast Du selbst bei nem Controllerfehler noch Deine Daten!

Und am besten auf oberster Ebene Freigabeordner anlegen - dann sind die Pfadnamen kurz.

Ziemlicher Unsinn deine Aussage. Entschuldige wenn ich dazu meine kritik anmerke. Da keine Parität in einem Raid 1 vorhanden ist wird das Filesystem über beide Platten ersichtlich sein. Klassischer Block Mirror. Natürlich Vorsicht bei Raid1 e und solchen spässen, aber klassisches Raid1 wirst du nie Probleme wie oben erwähnt haben, das ist faktisch nicht möglich da legidlich Blöcke abgeglichen werden. Ich würde zwei identische Disks nehmen und als Raid1 Konfigurieren, dass ist sauber und ersparrt dir im Fehlerfall unter umständen einen Datenverlust.