Schokolade schrieb:
Allerdings bleibt es einfach eine Sparmaßnahme der Hersteller [lokalen DRAM wegzulassen; Erg. Tsu]. Ich jeden Falls habe keine Lust auf Probleme, entweder gleich oder später die bei SSDs ohne DRAM auftreten bzw. auftreten können. (Mal von QLC abgesehen) Siehe z.B. hier
https://github.com/openzfs/zfs/discussions/14793
Und kann mich der Konklusion lediglich anschließen und jedem klar abraten so eine SSD zu kaufen.
Da geht einiges durcheinander, das hat mit lokalem Buffer nicht zu tun, sondern mit ungeeigneten Datenstrukturen bei der Blockverwaltung in der Firmware. (
Beispiel eines so ominösen Nachbesserns.)
Mit DRAM existiert das Problem, ist dir aber nur eine Zeit lang verborgen: Schaltest den Rechner währenddessen aus, dann kann es sogar zu Datenverlust kommen. Insbesondere wenn wg. „Performance“ der Controller darüber lügt, dass ein Block weggeschrieben (
sync) worden ist.
Unter Windows kannst du das, glaube ich, im Taskmanager über „Aktivitätszeit“ bzw.
command response-time Messungen nachvollziehen. Die sind irgendwann im hohen Millisekunden Bereich – und dann blockt entweder der Controller, sofern
command queueing nicht unterstützt wird oder der Buffer voll ist, und/oder der keinen Buffer hat um das zu maskieren; oder ZFS das zu lange warten musste.
Zumindest im Enterprise-Umfeld geht der Abnahmetest auch so, dass man die Platte schlimmstmöglich fragmentiert (zu 90%+ voll schreiben, 7% löschen, schreiben, löschen…) und am Ende die Performance bei fragmentierten 90% Füllstand misst. Damit meine ich, Schreibraten, Latenz usw.
(Um unnötiges (hier: dreifaches!)
reordering zu vermeiden sollte zumindest in der Entwicklung auch nicht
mq-deadline o.ä. sondern
elevator=noop oder
=none gesetzt werden. Usw. usf.)