Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Naja, die 8tb kingston SATA kostet knappe 700€, wennst davon 2 Stück rein machst sollte das wieder soweit gut sein.
special-vdev kann man auch machen, aber ssd mit ssd? ich weiss nicht... ob das so viel bringt?
Mit HDD Teilen kann man natürlich, aber unter 300€ bekommst auch keine sinnvolle HDD, da könntest dein Pool zumindest um eine SSD erweitern ums gleiche Geld (3x 330€ vs 1x 680€), ist leiser, sparsamer und du hast auch wieder Luft. Im Z1 hast jetzt aus 4 8er SSDs 24tb, mit 5 8er ssds hättest dann 32tb... wenn deine 24tb jetzt zu 80% voll sind wären das mit einer weiteren 8er nur mehr 60%...
Sind eh SATA, die du da hast, oder?
Ich denke die Kingston DC600M ist in jeder Hinsicht überlegen, wäre jetzt kein großer Schaden, ein Stück als Soforthilfe ins Pool zu stecken.
Hmmm ich häng mioch mal da kurz rein mit einer Frage xD auf meinem Daily_server läuft ZFS on top von dm_crypt (weil kein AVX2) - alles auf einer SSD.
Aber zpool trim "tank" funktioniert nicht - und fstrim geht auch nicht.
Heisst das ich kann das dann eigentlich gar nicht trimmen? oder müsste auf ZFS Crypt gehen, was halt in dem Fall leider ein CPU Upgrade erfordern würde.
Code:
root@shuttle-dailyserver:/# zpool get all tank | grep trim
tank autotrim on local
root@shuttle-dailyserver:/# zpool trim tank
cannot trim: no devices in pool support trim operations
root@shuttle-dailyserver:/#
Kann ich eventuell mit der Blocksize spielen um das Ganze performanter zu gestalten?
Bin folgende Punkte am ueberlegen:
Große, statische Daten (Bilder und so Zeug) auf spinning Rust und der restliche Kleinschiss, der mich ankotzt wenns lahm ist bleibt auf dem SSD Pool?
Naja, die 8tb kingston SATA kostet knappe 700€, wennst davon 2 Stück rein machst sollte das wieder soweit gut sein.
special-vdev kann man auch machen, aber ssd mit ssd? ich weiss nicht... ob das so viel bringt?
SSD haben ca 50k iops und benötigen Trim. Intel Optane hat 500k iops und benötigt grundsätzlich kein Trim. Damit bringt das schon was auch bei einem SSD Pool, halt nicht ganz soviel wie bei einem HD Pool mit 100 iops per Platte,
SSD haben ca 50k iops und benötigen Trim. Intel Optane hat 500k iops und benötigt grundsätzlich kein Trim. Damit bringt das schon was auch bei einem SSD Pool, halt nicht ganz soviel wie bei einem HD Pool mit 100 iops per Platte,
Ich meinte nicht die Kingston SATA als svdev, sondern als Speichererweiterung... mit meiner Vermutung, dass das Geld in einer Speichererweiterung vllt. besser angelegt ist als in einer ziemlich teuren SSD, die man als svdev verwenden könnte... also Optane etc... zudem müsste dafür ja PCIe (M.2, U.2 etc.) frei sein...
Ja schon, aber wenn der Datenträger "als ganzes" drin hängt, kann der Befehl wohl "durchgegeben" werden, was offenbar nicht funktioniert, wenn nicht "der ganze" Datenträger sondern eine Partition drin hängt... also müsste man wohl irgendwie den Datenträger selbst ansprechen - wofür mir die magischen Worte aber nicht bekannt sind.
So in etwa hab ich das gemeint, ob man das Trim "eine Ebene darunter" befehligen kann, also trim /dev/sdx ... oder so irgendwas...
Nochwas... p4n0 sollte uns (zumindest mir, ich bin neugierig) mal verraten, was er als "zu langsam" und "ausreichend schnell" empfindet... das wäre vllt. gut zu wissen. Dem einen hier reichen 1gbit, der andere braucht/will 100gbit ... insofern wüsste ich gern, wovon wir eigentlich reden.
Naja, die 8tb kingston SATA kostet knappe 700€, wennst davon 2 Stück rein machst sollte das wieder soweit gut sein.
special-vdev kann man auch machen, aber ssd mit ssd? ich weiss nicht... ob das so viel bringt?
Im Z1 hast jetzt aus 4 8er SSDs 24tb, mit 5 8er ssds hättest dann 32tb... wenn deine 24tb jetzt zu 80% voll sind wären das mit einer weiteren 8er nur mehr 60%...
Großes Obacht:
1. wenn das ein Produktives System ist hätte ich immer noch Bauchschmerzen, ein RaidZx zu erweitern.
2. Wenn der Pool wie auch immer erweitert wurde: er bleibt erstmal langsam bzw. wird noch langsamer. ZFS kennt kein „re-Balance“, d.h. alle neuen writes gehen hauptsächlich auf die neuen devices, und die alten bleiben zu 80% gefüllt und damit so langsam wie zuvor. ‼️
Man kann mit so etwas wie Diesem re-balancing Script etwas Verbesserung bringen, idealerweise aber Pool zerstören und neu erstellen (so man denn genügend Platz woanders hat um den kompletten Pool wegzusichern).
Nur Metadaten ist blöd und mit 100 GB kann man alle Dateien komprimiert <64K oder sogar 128K darauf ablegen. Das 80% oder SSD Trim Problem betrifft Optane nicht, da da jede Zelle wie bei RAM direkt ansprechbar ist. Auch ist die Belegung des Special Vdev zum Zeitpunkt des Hinzufügens bei 0%. Dem fast vollen Pool hilft das auch da er keine kleinen Writes mehr bekommt
Dass die Optane dieses Problem nicht hat, ist mir eh klar.
Aber ich meinte eben, obs das jetzt bestehende Problem denn lösen würde.
Ist es denn nicht auch so, dass auch größere Daten bei hohem Füllstand schlecht zu lesen sind, da es eben keine echten seq. writes sind, oder irre ich da jetzt?
PCIe Slots werd ich an dem kleinen µATX Board keine opfern.
Denke es wird darauf hinauslaufen dass ich iwann n paar neue SSDs organisiere, den kompletten Pool Plattmache, neu aufsetze und ausm Backup zurueckspiele.
Dann ist auch alles einmal aufgeraeumt und sauber.
Der 'lausige' speed außert sich bei folgendem Szenario:
Ich schreibe irgendwelchen Kleinschiss von meinem PC aus per SMB auf den Pool. Das rennt dann im Schnitt mit 0-50mbit.
Das war frueher definitiv deutlich schneller (iwo im bereich ~200mbps ++).
Und bei viel Kleinkram dauert das einfach lange. Auch Loeschoperationen etc. brechen einfach stark ein. Das macht das ganze Handling keinen Spaß mehr.
Sobald die Dateien etwas groeßer sind geht alles sehr zuegig, das ist kein Thema.
Danke aber an alle Helfer hier, wieder was gelernt
Dass die Optane dieses Problem nicht hat, ist mir eh klar.
Aber ich meinte eben, obs das jetzt bestehende Problem denn lösen würde.
Ist es denn nicht auch so, dass auch größere Daten bei hohem Füllstand schlecht zu lesen sind, da es eben keine echten seq. writes sind, oder irre ich da jetzt?
Da die gespeicherten Daten bleiben wo sie sind, ändert sich da nichts Auch neue Daten deren recsize > small blocksize landen auf HD. Nur neu geschriebene kleinere Dateien und Metadaten landen auf dem special vdev. Bei 128K Small Blocksize landet aber ziemlih alles bis auf Mediafiles da. Da muss man dann schon aufpassen dass die nicht vollläuft. Man kann aber mehrere Special Vdev Mirror haben.
2. Wenn der Pool wie auch immer erweitert wurde: er bleibt erstmal langsam bzw. wird noch langsamer. ZFS kennt kein „re-Balance“, d.h. alle neuen writes gehen hauptsächlich auf die neuen devices, und die alten bleiben zu 80% gefüllt und damit so langsam wie zuvor. ‼️
Hmm ne das kann aber nicht sitmmen dann würde doch Raid Funktionalität verloren gehen es muss doch zwingend gleichmässig geschrieben werden, damit bei raidz1 z.b. eine beliebige HDD ausfallen darf egal ob bei neuen oder alten Daten ohne dass das Auswirkungen hat. Man hat zwar kein Rebalance aber ein reflow - die Leseperformance der Altdaten vebrssert sich nicht - aber die aller neuen dann schon ide haben dann das neue perfekte Balancing.
Wenn man Altdaten (intern) umkopiert (denke moven reicht vermutlich nicht) wegen COW verbessert sich deren Performance dann aber auch, denn da findet dann ein Rebalance statt.
Neue Daten würden hier im Bild dann gleichmässig in 21,22,23,24,25 landen
Es gibt ja im Internet so Konzeptbilder von den Entwicklern da sieht man das auch - es ist immer auch beim Erweitern gewährleistet dass die RAID Funktion erhalten bleibt und es wird beim Erweitern krass umgeschaufelt, dass dem so ist.
ich meine nein.
wäre zwar eine technische mögliche Option, hätte aber den Nachteil dass im Crashfall der Cache nicht persistent wäre. Der L2Arc wird daher meines Wissens laufend aktualisiert. L2Arc kostet etwas Performance vor allem beim Reoot. Persistent L2Arc ist meines Wissens daher bei TrueNAS per default sogar deaktiviert.
Nicht unbedingt.
Ich meinte, es wäre ja machbar, im Shutdown-Fall den ARC in den L2ARC zu "schieben", und somit das "weniger Aktuelle" im L2ARC durchs "Aktuellere" ausm ARC zu ersetzen, wodurch beim Booten im L2ARC der "wertvollere" Datensatz liegen würde.
Muss ich mir mal ansehen, wie frage ich das richtig ab?
Ich meine gelesen zu haben, dass das wohl von der Version abhängt, da das mal wegen irgend einem Bug default deaktiviert wurde, keine Ahnung wie da momentan der Status ist.
Ja, für Core... 🙈
Das mit dem Tuneable kenn ich eh.
Gibts ein Command, mit dem ich den momentanen Status abfragen kann?
Sorry, ich bin allgemein (noch) nicht so fit in der ganzen Terminal-Sache und UNIXen im allgemeinen. 🙈
Es kam eine einzelne 22TB Toshiba ausm Mindstar Deal in die Maschine.
Backups sind vorhanden, darum darf das Ding alleine laufen.
Medienkram landet dadrauf und SSD Pool wurde entruempelt. Jetzt fliegt die Kiste wieder wie sie soll. Vielen Dank an alle Helfer
Was sagt das ZFS-Konsil denn zu einem raidz1 mit 4x 24TB HDDs? Will mein raidz2 mit 7x10TB im Dauerlaufsystem ersetzen weil der Platz so langsam knapp wird und ich die Platten reduzieren will.
Und was ersetzt Optanes, jetzt wo die nicht mehr so wirklich verfügbar sind?
Joa, wenn das Geld da ist, warum nicht?
War erschrocken, als ich gesehen habe, dass die HC560 (20tb) nun statt ca. 350€ eher 450€ kostet... Hätte gleich noch mehr kaufen sollen.
Kein Plan welche Platten du kaufen willst, klingt für mich aber nach hart über 2000€ Invest. Bäm.
Was machst mit den 10ern, ein MC12LE0 kaufen und nen Backupserver machen? Das ist so mein Plan für meine "alten" 8er und 10er.
bei derat großen Einzelplatten ist m.e. die Gefahr beim resilvern viel zu groß wenn währenddessen eine zweite HDD aussteigt. Das resilvern wird tagelang dauerstreß für deine Platten bedeuten.
Die Zeit von Hybridpools mit mechanischen Platten, und Optane Slog bei Notwendigkeit von sync write läuft ab
weil man heute dann eher Flash only Pools nutzt.
1. Man bekommt aber noch Optane, teils gebraucht oder pci-e oder U.2 statt M.2
Hinweis: Wenn man Optane als Slog möchte, so bringt das umso mehr je größer der Performanceunterschied zum OnPool ZIL ist,
wobei bei größeren Optane würde ich die eher als special vdev Mirror nehmen und per recsize <= small blocksize alle small io eines sync Dateisystems darauf ablegen..
2. Wenn man sehr schnellen Flashspeicher mit PLP als Pool hat, braucht man kein Slog um auch mit sync schnell zu sein, Optane bringt da nur geringen zusätzlichen Vorteil
Bei langsamerem Flash sähe das anders aus aber, man muss halt etwas besseres für den Pool nehmen, https://geizhals.de/?cat=hdssd&xf=2236_150~4643_Power-Loss+Protection
Das kommt ja auch immer drauf an wie voll die HDDs sind, meine 9x22TB Server braucht ~ 11h für scrubbing und ~ 1 Tag für resilver bei ~ 50% Belegung
Das auch kein Dauerstress für die anderen HDDs - das wäre es nur wenn auf alle HDDs dauernd geschrieben werden würde, also z.B. ein Reflow des ZFS Resilver heisst ja von (n-1) HDDs wird nur gelesen - in der CPU/Ram berechnet was fehlt - und das auf 1 HDD - die neue - geschrieben. Nur Lesen ist eher kein Stress für HDDs, zumal ja das lesen eher lahm erfolgt, weil ZFS parallel liest.
Wird auf die Neue mit 300 Mb/s (angenommen das sei deren techn Spec) geschrieben wird von den anderen 3 jeweils nur mit 100 Mb/s gelesen (sieht man ja mit iostat dass das eigentlich immer perfekt verteilt ist)
Das ist für die HDDs nichts stressiges, wichtiger ist eher dass das Gehäuse gut belüftet ist denke ich.
Resilver liest ja zunächst alle Metadaten um herauszufinden welche die Daten auf der defekten Platte waren. Das unterscheidet ZFS von klassischem Raid wo ein Rebuild immer die komplette Platte aus den anderen erstellt auch wenn die Platte fast leer war. ZFS kopiert nur die wirklichen Daten nicht dumm Sektoren und Blöcke.
Die Ergebnisse werden dann zunächst sortiert, damit mit möglichst wenig Zugriffen die Daten kopiert werden.
Die benötigte Zeit hängt damit in erster Linie von der Datenmenge ab die bearbeitet werden muss, dann von der iops Leistung des Pool beim Zugriff auf Metadaten und Daten und nicht zuletzt von der Fragmentierung.
@pwnbert Ja, billig wird das nicht. Angeblich ist wegen dem ganzen AI-Hype auch die Nachfrage nach Plattenplatz größer und Überkapazitäten scheinbar nicht mehr das Thema... Soll wohl noch teurer werden.
Aber voll ist halt voll und als (Zitat meine Frau: ) Datenmessi fällt es mir einfach schwer, irgendwas zu löschen. ;-) Na gut, wenns dann wieder 6-7 Jahre oder länger hält....
Die 10er sollen dann ins Backup-System, als raidz2 mit 8 Platten, was sich dann schlafen legen darf, wenn nicht gebackuped wird. Dumm ist nur, dass entweder das Produktivsystem oder das Backupsystem ein Ugreen NASync DXP8800 wird und somit weder ESXi noch Illumos drauf lauffähig sind, weils für diesen Aquantia 10G NIC nur Linuxtreiber gibt... Bleibt eigentlich nur Unraid oder TrueNAS Scale. Und soweit ich das hier gelesen hab, ist zfs send von OmniOS zu open ZFS nicht so wirklich möglich... Grmpf.
@LuxSkywalker ich hab nen scrub job für meinen aktuell 7x10TB raidz2 pool eingerichtet. Der läuft schon 3-4 Jahre. Der Pool ist mittlerweile zu 88% voll. Dauert 17h 19min 34s. Keine Probleme bisher.
Ich seh das auch so wie @HansBohne , dass ein resilver nicht mehr Stress bedeutet, als ein scrub. Dem Argument, dass die Platten bei nem scrub oder resilver eher mal sterben stimm ich bei nem Pool der dauerhaft Last hat zu, aber in so nem Homesetup, wo das als Datengrab dient, ist das imho das Risiko wert, vor allem wenn man ein Backupsystem hat.
@gea ja, ich werd dann parallel noch ein flash only system aus einem Ugreen NASync DXP480T aufbauen, auf dem dann die Workloads drauf liegen. In das DXP8800 mit den Platten würden zwar zwei M.2 zusätzlich rein passen, aber eigentlich kann ich auf den cache / special vdev auch verzichten...
Mir kam grad folgendes...
Wenn man aus nem pool (sagen wir raidz2) ne funktionierende Platte offline nimmt, dann kann man die ja etwas später wieder rein stecken und ZFS resilvert nur das Delta und nicht alle Daten. Dazu folgende Fragen/Überlegungen:
Was, wenn ich ein raidz2 aufbaue , was schon gut mit Daten gefüllt ist. Dann nehm ich betriebsmäßig eine Platte offline und leg sie für ne gewisse Zeit (sagen wir mal eine Woche) schlafen. Dann nehm ich sie wieder online, resilver das Delta. Jetzt nehme ich ne andere Platte offline und wiederhole das und rotiere so die Platten durch.
Wäre das eine praktikable Strategie um Strom zu sparen, weniger Hitze zu produzieren und die Platten gleichmäßig abzunutzen (Uptime)?
Hot spare ist ja so ein ähnliches Konstrukt, nur dass halt bei nem Ausfall der Platte immer alle Daten resilvered werden müssen, was unweigerlich länger dauert und mehr Stress erzeugt, als wenn man immer nur nen Deltasync machen muss.
Ich nehme an, dass ZFS sowas out of the Box nicht mitbringt. Aber könnte man das auf Applikationsebene implementieren?
Beitrag automatisch zusammengeführt:
Achso, ganz vergessen zu erwähnen:
Habe ne Auswahlbestellung mit vier unterschiedlichen 24TB-HDDs und einer 22TB-HDD aufgegeben. Mal sehen welche mir am besten zusagt... Wichtig ist mir Lautstärke im idle und unter Last und Stromverbrauch/Wärmeentwicklung.
Die 10er sollen dann ins Backup-System, als raidz2 mit 8 Platten, was sich dann schlafen legen darf, wenn nicht gebackuped wird. Dumm ist nur, dass entweder das Produktivsystem oder das Backupsystem ein Ugreen NASync DXP8800 wird und somit weder ESXi noch Illumos drauf lauffähig sind, weils für diesen Aquantia 10G NIC nur Linuxtreiber gibt... Bleibt eigentlich nur Unraid oder TrueNAS Scale. Und soweit ich das hier gelesen hab, ist zfs send von OmniOS zu open ZFS nicht so wirklich möglich... Grmpf.
Probleme gibts nur von/nach native ZFS von Oracle. OmniOS nutzt Open-ZFS.
Mit napp-it cs kann man ZFS auf OmniOS und beliebigem Linux/BSD managen und von/nach any replizieren.
