[Sammelthread] ZFS Stammtisch

Zur Problemlösung kann ich nicht beitragen, vielleicht hilft es aber die Ursache zu kennen.

Als ZFS bei Sun etwickelt wurde, haben die die iSCSI, NFS und SMB Freigabe als Eigenschaft eines ZFS Dateisystems definiert und dazu die entsprechenden Serverdienste in ZFS und den Solaris Kernel integriert. Bei Solaris und den freien Solaris Forks ist es heute noch so dass da nicht nur der Kernel gepflegt wird sondern auch die integrierten Server und Netzwerkdienste Deshalb tut es da out of the box.

Bei Linux gibt es diese Dienste nicht im Kernel sondern z.B. mit SAMBA als OS unabhängigen SMB Server. Der soll überall funktionieren und dem ist es zunächst egal auf welchem Dateisystem er arbeitet. Konfiguriert wird er überall gleich über die smb.conf.

Um also wie unter Solaris das Sharing über ZFS Attribute zu erledigen, muss SAMBA entsprechend konfiguriert werden. Ein Rechteproblem ist das aber definitiv nicht.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Zur Problemlösung kann ich nicht beitragen, vielleicht hilft es aber die Ursache zu kennen.

Als ZFS bei Sun etwickelt wurde, haben die die iSCSI, NFS und SMB Freigabe als Eigenschaft eines ZFS Dateisystems definiert und dazu die entsprechenden Serverdienste in ZFS und den Solaris Kernel integriert. Bei Solaris und den freien Solaris Forks ist es heute noch so dass da nicht nur der Kernel gepflegt wird sondern auch die integrierten Server und Netzwerkdienste Deshalb tut es da out of the box.

Bei Linux gibt es diese Dienste nicht im Kernel sondern z.B. mit SAMBA als OS unabhängigen SMB Server. Der soll überall funktionieren und dem ist es zunächst egal auf welchem Dateisystem er arbeitet. Konfiguriert wird er überall gleich über die smb.conf.

Um also wie unter Solaris das Sharing über ZFS Attribute zu erledigen, muss SAMBA entsprechend konfiguriert werden. Ein Rechteproblem ist das aber definitiv nicht.

Ja, dass die Sache unter Solaris so ist, weiß ich schon, ich möchte aber aus verschiedenen Gründen bei Linux bleiben. Samba läuft auch und ein Share, den ich manuell in die smb.conf eintrage funktioniert. Irgendwo hab ich gelesen, dass "zfs set=smaresmb pool/dataset" bzw. "zfs share pool/dataset" im Hintergrund Sambas "net share add" Befehl aufruft. Tut aber bei mir alles nicht. In den ZFS on Linux spezifischen Anleitungen bzw. Blogs, die ich gefunden habe, sieht es auch immer so aus, als müsste das tatsächlich so einfach funktionieren, aber bei mir geht's eben nicht. Zur Not bleibt mir ja noch als Option doch meine Shares von Hand zu verwalten, muss man ohne ZFS ja ohnehin machen, also egal. SMB ist bei mir ohnehin kaum relevant, nur meine Frau will mit Windows zugreifen, "meine" Desktop-Rechner sind fast alle mit Arch-Linux bespielt und greifen per NFS auf die Shares zu. Nur mit dem Mac gehe ich manchmal mit CIFS an einen Share, weil da die UIDs nicht gesynct hab.

"Produktiv" hab ich seit Jahren FreeNAS laufen und bin sehr zufrieden. Ich experimentiere aber gerade auf einem "Laborrechner" mit Proxmox, weil ich die Virtualisierung charmant finde und überlege umzustellen. Bei Proxmox muss ich eben alles von Hand machen, was mit FreeNAS schon funktioniert, ich frage mich z.B. auch, ob ich dann auf NFS4 wechsel, womit ich bisher keine Erfahrung habe, wechseln soll, da es da ja dann keine Notwendigkeit gibt die UIDs zu syncen. Naja, mal sehen, ich hoffe bis Weihnachten sind alle Probleme gelöst, das habe ich mir mal als Ziel für den Umstieg gesetzt.
 
Ich habe ein Problem mit dem CIFS-Server von OmniOS in Verbindung mit einer Windows Domaine. Folgendes Setup:

AllInOne System mit VMWare ESXi, einem virtualisierten OmniOS, LSI Controller durchgereicht, Windows Server 2012 R2 virtualisiert. Dann einen ZFS Filesystem erzeugt, anschließend Aufnahme in die Windows Domaine. Alles Prima, Rechte, Lese, schreiben etc. funktionieren wie erwartet. Dann Reboot um zu sehen, wie sich der CIFS-Server verhält wenn nach einem Neustart zunächst der Domain Controller nicht da ist. Der CIFS-Server fällt auf die Nase mit Maintenance Modus und lässt sich danach gar nicht mehr starten obwohl der Domain Controller da ist.

Fehlermeldung:

smb/cifs-server: maintenance
svc:/network/smb/server : default (smbd daemon)
State: maintenance since Fri Oct 23 15:54:04 2015
Reason: Method failed.
See: SMF-8000-8Q
See: smbd(1M)
See: /var/svc/log/network-smb-server : default.log
Impact: This service is not running.


/var/svc/log/network-smb-server : default.log:
smbd: NetBIOS services started
smbd: can't resolve name"", node name or service name not known
smbd: service initialized


Verstehe nicht warum hier keine name auftaucht: can't resolve name"" ??

Unter napp-it -> home Services SMB Active Directory steht aber korrekt:

Current membership: domain [COCO] [*] [coco.site]
 
Zuletzt bearbeitet:
Hallo Zusammen,

ich hätte eine Frage, die aktuell nicht zur Diskussion passt aber Ihr mir dennoch sicher beantworten könnt.

Aktuell läuft mein Server Daheim mit einem LSI 1068E Controller mit IT Firmware an dem 8 Platten hängen (maximal 2 TB). Langsam wird der Speicher etwas eng und ich muss mir überlegen, wie ich diesen kommenden Engpass umgehen kann. Der aktuell von mir eingesetzte Controller, kann meines Wissens nach nicht mehr als 3 TB Platten betreiben. Welchen Controller würdet Ihr mir denn aktuell Empfehlen (der bezahlbar ist), um mindestens 8x6TB Laufwerke zu unterstützen?
 
Ich habe ein Problem mit dem CIFS-Server von OmniOS in Verbindung mit einer Windows Domaine. Folgendes Setup:

AllInOne System mit VMWare ESXi, einem virtualisierten OmniOS, LSI Controller durchgereicht, Windows Server 2012 R2 virtualisiert. Dann einen ZFS Filesystem erzeugt, anschließend Aufnahme in die Windows Domaine. Alles Prima, Rechte, Lese, schreiben etc. funktionieren wie erwartet. Dann Reboot um zu sehen, wie sich der CIFS-Server verhält wenn nach einem Neustart zunächst der Domain Controller nicht da ist. Der CIFS-Server fällt auf die Nase mit Maintenance Modus und lässt sich danach gar nicht mehr starten obwohl der Domain Controller da ist.

Fehlermeldung:

smb/cifs-server: maintenance
svc:/network/smb/server : default (smbd daemon)
State: maintenance since Fri Oct 23 15:54:04 2015
Reason: Method failed.
See: SMF-8000-8Q
See: smbd(1M)
See: /var/svc/log/network-smb-server : default.log
Impact: This service is not running.


/var/svc/log/network-smb-server : default.log:
smbd: NetBIOS services started
smbd: can't resolve name"", node name or service name not known
smbd: service initialized


Verstehe nicht warum hier keine name auftaucht: can't resolve name"" ??

Unter napp-it -> home Services SMB Active Directory steht aber korrekt:

Current membership: domain [COCO] [*] [coco.site]

Wenn der AD Server beim Hochfahren nicht da ist, sollte der SMB Service trotzdem starten, eine Anmeldung dann aber nur als lokaler User möglich sein. Um wieder in die Domäne zu gelangen, muss der SMB Dienst neu gestartet werden.

Was passiert denn, SMB Service anhält und wieder startet bzw OmniOS neu startet.


Info am Rande
Gordon Ross (Nexenta), der den SMB Server auch für Illumos pflegt, hat größere Überarbeitungen der Domänenunterstützung vorgenommen. https://www.illumos.org/issues/1087

Laut einer Mail von ihm in der Illumos dev-Maillingliste soll demnächst SMB2 für Illumos (OI, OmniOS) und den Kernel-SMB Server kommen so dass man z.B. als Mac-User nicht mehr auf Oracle Solaris 11.3 oder SAMBA ausweichen muss.

- - - Updated - - -

Hallo Zusammen,

ich hätte eine Frage, die aktuell nicht zur Diskussion passt aber Ihr mir dennoch sicher beantworten könnt.

Aktuell läuft mein Server Daheim mit einem LSI 1068E Controller mit IT Firmware an dem 8 Platten hängen (maximal 2 TB). Langsam wird der Speicher etwas eng und ich muss mir überlegen, wie ich diesen kommenden Engpass umgehen kann. Der aktuell von mir eingesetzte Controller, kann meines Wissens nach nicht mehr als 3 TB Platten betreiben. Welchen Controller würdet Ihr mir denn aktuell Empfehlen (der bezahlbar ist), um mindestens 8x6TB Laufwerke zu unterstützen?

LSI 1068 kann maximal 2TB.
Als Alternative würde ich einen LSI 9207 nehmen. Der kommt bereits mit IT Firmware
Alternativ was billigeres zum Umflashen wie IBM 1015 oder Dell H200 (Umflashen auf LSI 9211-IT mode)
 
LSI 1068 kann maximal 2TB.
Als Alternative würde ich einen LSI 9207 nehmen. Der kommt bereits mit IT Firmware
Alternativ was billigeres zum Umflashen wie IBM 1015 oder Dell H200 (Umflashen auf LSI 9211-IT mode)

Dann sind meine Recherchen ungenau gewesen. Vielen Dank an euch beide für eure Tipps. Dann schau ich mal rum, wo ich die Teile für nen vernünftigen Preis ranschaffen kann.
 
Verständnisfrage zu SSD's mit ZFS

Frage: Bei SSD's heisst es ja, man soll eine gewisse größe für "Over Provisioning" bereit stellen, oft gelesen hab ich von ~10%.
Wie mache ich das aber nun, wenn ich die SSD's für ZFS her nehme? Reicht es da, wenn ich mit "zfs set quota" die nutzbare Grösse auf 90% beschneide oder musss/darf die Parttion die ZFS nutzt, nur 90% groß sein?
 
Man muss hier unterscheiden.

ZFS wird als Copy On Write Dateisystem wegen der Fragmentierung langsamer wenn der Pool sagen wir mal zu mehr als 80% gefüllt wird. Das betrifft aber normale Platten, keine SSDs weil es da das Fragmentierungsproblem nicht gibt. Hier machen Reservierungen auf Poolebene (nicht Quotas) Sinn.

Bei SSDs macht man OverProvisioning aus einem anderen Grund. Hier geht es darum die interne Verwaltung der SSD durch den SSD Controller zu unterstützen (Garbage Collection etc) damit die SSD unter Last oder mit höherem Füllgrad beim Schreiben nicht langsamer wird. Professionelle SSDs haben hier ein internes Overprovisioning bis zu 40%, sehr gute Consumer SSDs ca 10% (das sind dann z.B. SSDs die als 480GB Platten verkauft werden statt den 512GB die tatsächlich eingebaut sind).

Wenn man aus diesem Grund Overprovisioning macht, braucht man eine neue SSD, bei der man leere Bereiche vor überschreiben sperrt. Die beste Methode dazu ist eine Host Protected Area (https://de.wikipedia.org/wiki/Host_Protected_Area) die man z.B. mit Hdat2 anlegen kann.

Mehrere Partitionen gehen auch, nur ein Quota nützt aber nichts weil nicht der Füllgrad entscheidend ist sondern dass Bereiche nur vom Controller zur internen Optimierung genutzt werden. SSD-Leistung optimieren - Over-Provisioning nutzen | TecChannel.de
 
Zuletzt bearbeitet:
Oder man hat TRIM. In Kombination mit dem freien Platz, den man ZFS eh lassen sollte, ist das doch die perfekte Lösung, oder nicht?
 
Hi GEA, danke für die Info.

Das betrifft aber normale Platten, keine SSDs weil es da das Fragmentierungsproblem nicht gibt. Hier machen Reservierungen auf Poolebene (nicht Quotas) Sinn.
Das verstehe ich jetzt nicht ganz. Daß das bei SSD's dann keinen Sinn macht ist nun klar, aber was meinst Du dann im nächsten Satz mit "Hier machen Reservierungen auf Poolebene (nicht Quotas) Sinn." ?
Sinn in Bezug auf was?

Wenn ich das dann richtig verstanden hab heisst das nun, entweder muss die Platte mit einem Tool wie "Hdat2" bearbeitet werden, damit das Betriebssystem nur noch z.B. 90% der Platte sieht (für das BS sind die 90% dann 100%) oder ich muss händisch eine Partition anlegen mit 90% Grösse und den Rest frei lassen und ZFS dann diese Partition zuweisen ?


Oder man hat TRIM. In Kombination mit dem freien Platz, den man ZFS eh lassen sollte, ist das doch die perfekte Lösung, oder nicht?
Ich nutze ZoL, soweit ich weiß unterstützt das leider noch kein TRIM.
 
Zuletzt bearbeitet:
Mit Reservierung auf den Pool (z.B. 10%) kann man dafür sorgen,
dass der Pool niemals mehr als zu 90% gefüllt wird (Freier Platz = 90%)

Eine HPA von 10% bei einer 100GB Platte sorgt dafür, dass für das OS die Platte nur noch als 90GB sieht.

Trim ist bei Raid oft ein Problem/nicht verfügbar und verringert auch die Performance.
Moderne SSDs und Overprovisioning ist aktuell die beste Lösung.
 
Ich würde von solchen haarsträubenden Frickeleien die Finger lassen. Nutz einfach einen Bereich der SSD nicht. Die SSD interessiert nicht, ob der Bereich nicht genutzt wird oder ob es eine HPA ist.

Wichtig ist nur, dass der SSD eindeutig bekannt ist, dass der Bereich entweder nie genutzt wurde oder definitiv nicht mehr genutzt wird (durch TRIM).
 
Nicht Angst machen.

HPAs sind keine Frickelei sondern ist gängige Tuningpraxis um die Performance von SSDs bei hoher Schreiblast oder Füllgrad hoch zu halten. Ein Teil der Performance von Enterprise SSDs kommt ja gerade daher. Der Vorteil ist das es sich um ein set and forget handelt. Das OS sieht das einfach nicht.

Um HPAs anzulegen gibt es zwei Tools, Hdat für Dos oder hdparm für Linux.
https://www.thomas-krenn.com/de/wiki/SSD_Over-Provisioning_mit_hdparm

Und HPAs sorgen ja gerade dafür einen Bereich zu haben, der vom schreibenden OS nicht genutzt wird
und damit ausschliesslich dem Controller für Hintergrund Optimierungen zur Verfügung steht.

Man kann auch nichts kaputt machen da man alles rücksetzen kann.
 
Zuletzt bearbeitet:
Hallo zusammen,

ich benötige gerade einen neuen Proxmox Server, auf dem mehrere virtuelle Maschinen mit Web- und Datenbankservern laufen werden.

Ich tendiere dazu, meine bewährte LVM Konfiguration mal gegen ZFS einzutauschen und stehe nun vor folgender Frage: Welche HDD/SSD Variante würde wohl mehr Performance bringen (Hexacore mit 64 GB Ram):

1) 4x 600 GB SAS HDD
2) 2x 3 TB SATA HDD und 2x 240 GB SSD (als ZIL, L2ARC)

Ich befürchte fast, dass man das so allgemein nicht beantworten kann, aber vielleicht könnt ihr mir ja ein Hinweise geben oder von euren Erfahrungen erzählen.

Danke vorab!
 
Doch, kann man allgemein beantworten:
weder das eine noch das andere, sondern gute SSDs.

z.B. Intel SSDs 3610, 3700, 3710
wenn Schreibperformance im Vordergrund steht

oder Intel S3500
wenn Leseperformance ausreichend ist

oder künftig NVMe

btw
mit oder ohne ZFS
 
Doch, kann man allgemein beantworten:
weder das eine noch das andere, sondern gute SSDs.

z.B. Intel SSDs 3610, 3700, 3710
wenn Schreibperformance im Vordergrund steht

oder Intel S3500
wenn Leseperformance ausreichend ist

oder künftig NVMe

btw
mit oder ohne ZFS

Dass eine reine SSD-Lösung zu bevorzugen ist, ist mir schon klar (trotzdem danke).
Tatsächlich ist die Hardwareauswahl in diesem Fall aber leider vorgegeben (SSDs sind allerdings Intel Datacenter SSDs) und mit nur 2x240 GB komme ich nicht aus.
 
Dass eine reine SSD-Lösung zu bevorzugen ist, ist mir schon klar (trotzdem danke).
Tatsächlich ist die Hardwareauswahl in diesem Fall aber leider vorgegeben (SSDs sind allerdings Intel Datacenter SSDs) und mit nur 2x240 GB komme ich nicht aus.

Die genannten Intel Enterprise SSDs gehen bis 2 TB.
Ansonsten sind natürlich 4 SAS HDs (vor allem schnellere 10/15k) viel schneller als 3TB disks.
Ein ARC beschleunigt nur Lesen und bei sync-write kommt es auf die Performance des ZIL an.

Da aber 600GB SAS auch teuer sind, ist das Geschichte im Vergleich zu z.B. 800 GB Intel S3610.
Ich habe die gerade in unseren Mailserver eingebaut (statt älterer SSDs) und bin begeistert.
 
Um HPAs anzulegen gibt es zwei Tools, Hdat für Dos oder hdparm für Linux.
https://www.thomas-krenn.com/de/wiki...ing_mit_hdparm
Die Thomas-Krenn Anleitung ist ja eigentlich problemlos machbar, danke für die Info.

Sorry wenn ich jetzt noch mal fragen muss: Die zweite mögliche Varainte (ohne HPA) wäre, wenn ich eine GPT-Partition über nur 90% anlege die ZFS dann nutzt und die anderen 10% unpartitioniert bleiben, richtig?
 
Die genannten Intel Enterprise SSDs gehen bis 2 TB.
Ansonsten sind natürlich 4 SAS HDs (vor allem schnellere 10/15k) viel schneller als 3TB disks.
Ein ARC beschleunigt nur Lesen und bei sync-write kommt es auf die Performance des ZIL an.

Da aber 600GB SAS auch teuer sind, ist das Geschichte im Vergleich zu z.B. 800 GB Intel S3610.
Ich habe die gerade in unseren Mailserver eingebaut (statt älterer SSDs) und bin begeistert.

Klar bei einer Neuanschaffung würde SAS kaum Sinn machen, aber die Platten sind eben schon da.

Du meinst also, das 2x240 GB SSD als ZIL und L2Arc den Performance Nachteil von SATA gegenüber SAS nicht ausgleichen kann. Korrekt?
 
Es kommt auf den Anwendungsfall an.
Bei einem Webserver mit wenigen statischen Files kann der Pool beliebig langsam sein. Nach einiger Zeit werden bei ausreichend RAM 100% aller Dateien aus dem Ram geliefert (Zur Not aus dem L2Arc wenn mehr RAM nicht geht)

Selbst wenn nur 80% aller Reads aus dem RAM kommen, ist Pool-Performance nicht soo wichtig.

Performanceunterschiede ergeben sich vor allem beim Schreiben - besonders wenn transaktionssicheres sync write benötigt wird. Dann braucht man eventuell ein Extra ZIL Device- dann aber was echt schnelles.
 
Es kommt auf den Anwendungsfall an.
Bei einem Webserver mit wenigen statischen Files kann der Pool beliebig langsam sein. Nach einiger Zeit werden bei ausreichend RAM 100% aller Dateien aus dem Ram geliefert (Zur Not aus dem L2Arc wenn mehr RAM nicht geht)

Selbst wenn nur 80% aller Reads aus dem RAM kommen, ist Pool-Performance nicht soo wichtig.

Performanceunterschiede ergeben sich vor allem beim Schreiben - besonders wenn transaktionssicheres sync write benötigt wird. Dann braucht man eventuell ein Extra ZIL Device- dann aber was echt schnelles.

Die Webserver sind in der Tat unproblematisch. Mir machen allerdings die 3-4 MySQL Server sorgen, die durchaus einige Schreibzugriffe werden verarbeiten müssen. 2x Sata im Raid 1 macht das nicht mit und genau deswegen wird der Server ja getauscht. Nur weiß ich eben nicht, ob 4x 600 GB SAS im Raid 10 oder 2x Sata + 2x SSD mit ZFS die bessere Wahl sind.
 
Beim Schreiben muss man Arc/L2Arc und ZIL erstmal komplett ignorieren.
Eine sehr schnelle Platte macht ca 100 iops (Bei Datenbanken zählen eigentlich nur iops).
Ein Raid-Z (1-3) vdev macht auch nur 100 iops (da alle Platten positioniert werden müssen).

Eine SSD macht unter Last ca 5000 - 30000 iops, eine NVMe nochmal mehr.
Früher hat man massive Raid-10 Konfigurationen benutzt um iops zu verbessern, da
beim Lesen bei ZFS die iops mit der Anzahl der Platten skaliert, beim Schreiben mit der Anzahl der vdevs.

Bei sync write wird alles erst per sync write geloggt und dann per schnellem async per write cache geschrieben. Schreiben ist also niemals schneller als sequentiell über den Pool da sync write über das ZIL immer noch dazukommt.

Eigentlich ist es daher müßig, sich bei einem professionellen Setup um Performance bei Platten Gedanken zu machen wenn SSDs sequentiell ähnlich schnell sind, bei den wichtigeren iops aber 100x schneller. Wenn man aber aus Kostengründen Platten nimmt, kommt es bei sync write essentiell auf das ZIL an. Perfekt ist ein ZeusRam (Rambasiert). Gut sind Intel S3700. Künftig wird man wohl NVMe nehmen. Billige SSD als ZIL taugen nicht, machen alles eventuell sogar langsamer oder mangels powerloss protection sogar sync write unsicher..
 
Zuletzt bearbeitet:
Kewl, mal schauen ob man von der Beta auf final "updaten" kann.
 
Wenn der AD Server beim Hochfahren nicht da ist, sollte der SMB Service trotzdem starten, eine Anmeldung dann aber nur als lokaler User möglich sein. Um wieder in die Domäne zu gelangen, muss der SMB Dienst neu gestartet werden.

Was passiert denn, SMB Service anhält und wieder startet bzw OmniOS neu startet.

Vielen Dank gea, mir war wichtig zu verstehen, wie es eigentlich sein müsste. Ich habe mehrfach die Systeme gebootet und immer wieder den gleichen Fehler bekommen. Dann habe ich in der /etc/hosts den Domain Controller voll qualifiziert bekannt gemacht, also <IP-Adresse> servername.domainname.site etc. Danach war der Fehler weg und der SMB Dienst startet obwohl der DC noch nicht da ist und funktioniert normal, nachdem der DC dann gebootet hat. Schon merkwürdig.
 
Zuletzt bearbeitet:
HPAs sind keine Frickelei sondern ist gängige Tuningpraxis um die Performance von SSDs bei hoher Schreiblast oder Füllgrad hoch zu halten.

TRIM ist unter FreeBSD für ZFS verfügbar. Wenn man TRIM hat, sollte man es nutzen, weil man den freien Platz, den man für die SSD reserviert, mit dem Platz gleichsetzen kann, den man für gute ZFS-Performance freihält.

Man muss also nicht einmal Platz für die SSD reservieren und zusätzlich noch aufpassen, dass das ZFS nicht voll wird, sondern kann alles über den Füllgrad des Pools steuern, so dass man effektiv nur einmal Platz "wegwirft".
 
Trim ist praktisch in allen Betriebssystemen für Einzelplatten enthalten, jedoch so gut wie nie für Raid Konfigurationen. FreeBSD ab v10 soll zwar Trim auf Software Raid können. Dennoch setzen neuere SSDs eher auf eine SSD interne Garbage Collection die auch unabhängig vom Trim Support des Betriebssystems gut arbeitet. Genügend Intelligenz und Power des Controllers vorrausgesetzt weiss ja eine SSD selber welche Bereiche umorganisiert werden müssen oder frei sind oder kann Idle Phasen zur internen Optimierung nutzen.

Zusätzliches Overprovisioning ist eine Methode dies zu unterstützen bzw. billigerere Consumer SSDs näher an die Performance von Enterprise SSDs heranzuführen die ja auch einen Teil ihrer Performance daraus beziehen.

Unabhängig davon ist eine ZFS Reservierung um Fragmentierungsprobleme zu vermeiden bei SSD only Pools natürlich immer obsolet da SSDs auf alle Daten gleich schnell zugreifen können, egal wo sie liegen. Ein Overprovisioning ist da sinnvoller. Ob interne Garbage Collection mit Overprovisioning Trim ersetzen kann bzw inwieweit Trim das nochmal verbessert kann ich auch nicht sagen bzw hab dazu noch keine belastbaren Tests gesehen.
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh