SSD Haltbarkeit bei Einsatz als Build-System
-
hustbaer schrieb:
Ich würde da eher noch das RAM als Schwachstelle sehen, und dementsprechend ECC RAM empfehlen. Ein Dateisystem das Prüfsummen über Filedaten rechnet würde ich dagegen gerade nicht für ne Build-Maschine verwenden wollen. Weil es unnötig Performance verbrät, für etwas was aktuelle Hardware wirklich gut kann.
Die anderen Dateisysteme verbraten dafür die Performance, weil sie z.B. kein Copy on Write können.
Außerdem gibt's für ZFS noch ZIL und L2ARC die die Performance in speziellen Fällen verbessern können.
Das ist allerdings noch nicht alles. ZFS selbst nimmt sich viel RAM, damit werden die Performanceeinbußen hinfällig, weil man die Prüfsummen auch später ausrechnen kann.Richtig ist allerdings, dass man ECC RAM verwenden sollte. Aber wir reden hier von einem Build Server. Für eine Firma sollte so etwas drin sein.
Zumal bei größeren Projekten die Wahrscheinlichkeit steigt, dass sich Bugs in das Binary einschleichen, wenn das RAM nichts taugt und kein ECC beherrscht.Wie viel Software wurde da schon in die freie Welt entlassen, die den ein oder anderen Bug enthält nur weil das RAM nichts taugte. Kein Mensch hat hier Daten, aber ich könnte mir vorstellen, dass es solche Software gibt.
Und die Programmierer suchen sich nen Wolf, ändern ein Bisschen den Code und wundern sich dann, warum der Bug nun nicht mehr auftritt, dafür aber woanders ein Bug drin ist.
-
scrontch schrieb:
Es geht unter den Kollegen das Gerücht um dass die SSD nur nen paar Monate halten würde bei den vielen Wrties.
Meine SSD in der Arbeit dürfte schon vier Jahre alt sein, noch keine Probleme.
-
btrfs & zfs schrieb:
Die anderen Dateisysteme verbraten dafür die Performance, weil sie z.B. kein Copy on Write können.
Hm. Weiss nicht ob das wirklich viel bringt. Dazu wäre interessant wie oft bei einem Build Files nur blöd rumkopiert werden. Ich würde ja vermuten: nicht so wirklich oft.
btrfs & zfs schrieb:
Das ist allerdings noch nicht alles. ZFS selbst nimmt sich viel RAM, damit werden die Performanceeinbußen hinfällig, weil man die Prüfsummen auch später ausrechnen kann.
Ist die Frage ob man auf einer Build-Kiste RAM zu verschenken hat. Wir sicherlich nicht. Ich hab nen PC mit 32 GB, und wenn ich da linke kommt schon mal ein "out of memory".
-
hustbaer schrieb:
Ist die Frage ob man auf einer Build-Kiste RAM zu verschenken hat. Wir sicherlich nicht. Ich hab nen PC mit 32 GB, und wenn ich da linke kommt schon mal ein "out of memory".
Bei FreeNAS rechnet man für ZFS mit 1 GB RAM pro 1 TB Festplatte, wobei für FreeNAS mit 8 GB Minimum RAM gerechnet wird.
Der Trick ist nun, dass ein Buildserver normalerweise keinen großen Datenträger benötigt, das ist ja schließlich kein Archivierungsserver.
2 x 512 GB SSDs im Mirror Verbund sollten daher ausreichen.Nimmt man den gleichen RAM Bedarf, also 8 GB RAM für das OS und 1 TB für die 2 SSDs, dann sollte ein Rechner mit 48 GB RAM genügen, dann hast du noch 39 GB RAM für den eigentlichen Build übrig.
Ansonsten, einfach RAM kaufen, so teuer ist ECC RAM auch nicht. Die meisten Xeons können 64 GB an RAM verwalten.
-
Danke für die Beiträge.
Also OS/Filesystem stehen bei mir nicht zur Debatte, das ist Windows8 und NTFS.
Das ist übrigens kein dedizierter Buildserver sondern meine Developer-Arbeitsmaschine, aber ich builde/teste eben oft.
RAM hab ich 32GB und auch schon eine Ramdisk mit 2GB für den TEMP Folder von Visual Studio angelegt. Das hatte etwas Zeit gespart.
Disk Zugriff ist definitif ein Flaschenhals, da die meiste Zeit vom Build mit 100% Diskauslastung einhergeht, wogegen CPU 100% relativ selten ist. (Daten vom Windows Taskmanager). Wobei jetzt natürlich sein kann dass der Zugriff auf die Ramdisk ebenfalls zu Diskzeit zählt.
Ich seh schon, ich muss genauer schauen wieviel GBs konkret bei einem Build (komplett und inkrementell) geschrieben werden.
Aber die Lebensdauern von 1PtB writes bei SSDs hören sich gut an.
-
Also ich hatte erst auch Bedenken was die Lebenszeit von SSDs in Entwicklerrechnern angeht. In meiner letzten Firma hab' ich es innerhalb von 2-3 Jahren aber nur auf 2-3 TB Writes geschafft. Also weit weit weg von Mengen die ein Problem verursachen können. Selbst wenn du 100x so viel machst müsste deine SSD noch lange genug halten. Denn alle 4-5 Jahre mal ne neue SSD, das sollte wohl wirklich drinnen sein.
-
hustbaer schrieb:
Denn alle 4-5 Jahre mal ne neue SSD, das sollte wohl wirklich drinnen sein.
Mit ZFS oder btrfs wüßte er, wann die SSD schlapp macht.
Das läuft zwar nicht auf Windows, aber man könnte ja Windows in eine VM packen, dann wäre der Unterbau mit dem die Daten gespeichert werden trotzdem ZFS oder btrfs.
-
Für die meisten Benutzer dürfte die Haltbarkeit nicht das große Problem sein. Das sichere löschen von Daten ist das Problem. Bei HDDs ist das einfach zu bewerkstelligen, bei SSDs entscheidet der Controller wo was hingeschrieben wird. Sicheres löschen würde auch die Haltbarkeit beeinflussen.
-
Dafür gibt es bei SSDs Secure Erase... Dabei wird auch ein neuer Schlüssel generiert. Selbst wenn noch Daten vorhanden wären, ohne diesen Schlüssel wäre das nur noch Datenmüll. Sicheres Löschen ist also auch kein Problem.
-
Nur das Secure Erase eine Low-Level-Formatierung ist, und mit sicherem Löschen im Normalbetrieb rein gar nichts zu tun hat. Das mögen manche doof finden, es gibt aber auch Gründe für sicheres Löschen im Betrieb.
-
T300 schrieb:
Nur das Secure Erase eine Low-Level-Formatierung ist, und mit sicherem Löschen im Normalbetrieb rein gar nichts zu tun hat. Das mögen manche doof finden, es gibt aber auch Gründe für sicheres Löschen im Betrieb.
Dafür gibt's Verschlüsselung und die geht auch im Betrieb.
-
Ok, offensichtlich gibt es hier Klärungsbedarf:
Alle mir bekannten SSDs verschlüsseln die Daten beim Schreiben. Immer. Unabhänging von irgendeiner User-Einstellung. Das geschieht auf Hardwareebene innerhalb der SSD und kann nicht deaktiviert werden.Bei einem Secure Erase wird der alte Schlüssel durch einen neuen Schlüssel ersetzt. Die alten Daten sind ohne den alten Schlüssel aber nicht mehr entschlüsselbar.
Ich kann es nur für die alten SSDs von OCZ mit Sicherheit sagen, aber andere Hersteller werden es nicht anders machen: Da wird beim Secure Erase tatsächlich nur der Schlüssel getauscht und alle belegten Blöcke als gelöscht markiert. Den Rest erldigt der Trimbefehl irgendwann später. Trotzdem ist von den alten Daten nichts mehr lesbar. Auch eine Datenrettungsfirma kann nichts mehr machen, wenn der Bereich der SSD defekt ist, in dem der Schlüssel abgelegt ist, oder der Schlüssel neu generiert wurde.
-
-
SSDDSS schrieb:
https://www.computerwoche.de/a/die-geheimen-schwaechen-der-ssd,2501912,4
Was genau ist der Bezug zu einem Build-Agent-System? Die sitzt die ganze Zeit im Rechner und wenn ich sie wegwerfen will lasse ich sie professionell shreddern.
MfG SideWinder
-
btrfs & zfs schrieb:
hustbaer schrieb:
Denn alle 4-5 Jahre mal ne neue SSD, das sollte wohl wirklich drinnen sein.
Mit ZFS oder btrfs wüßte er, wann die SSD schlapp macht.
Soweit ich weiss tut Windows (ab Windows 7) SMART Daten auswerten und petzen wenn die Werte schlecht werden.
btrfs & zfs schrieb:
Das läuft zwar nicht auf Windows, aber man könnte ja Windows in eine VM packen, dann wäre der Unterbau mit dem die Daten gespeichert werden trotzdem ZFS oder btrfs.
Lol. Nein.
-
Million Voices schrieb:
Ok, offensichtlich gibt es hier Klärungsbedarf:
Alle mir bekannten SSDs verschlüsseln die Daten beim Schreiben. Immer. Unabhänging von irgendeiner User-Einstellung. Das geschieht auf Hardwareebene innerhalb der SSD und kann nicht deaktiviert werden.Falls du das so gemeint hast wie ich es jetzt verstehe, würde ich sagen: Dann kennst du nicht gerade viele SSDs. Es gibt nämlich genug die überhaupt nicht verschlüsseln. Gar nicht. Niemals.
Million Voices schrieb:
Bei einem Secure Erase wird der alte Schlüssel durch einen neuen Schlüssel ersetzt. Die alten Daten sind ohne den alten Schlüssel aber nicht mehr entschlüsselbar.
Die SSDs die überhaupt verschlüsseln können, machen das so, ja. Alles andere wäre auch beknackt.
-
Es würde mich erstaunen, wenn alle "verschlüsselnden" SSDs wirksam verschlüsseln würden. Bei einem Hardware-Unternehmen frickeln doch irgendwelche Praktikanten solche zweitrangigen Werbe-Features zusammen. Da wird dann eben blockweise irgendwie mit den gleichen Schlüssel und gleichem IV "verschlüsselt". "Das wird schon keiner innerhalb der Garantie reversen und wenn doch verklagen wir den einfach". Fertig.
-
@TyRoXx
Und ich glaube du hast keinen Plan wovon du da redest.
-
hustbaer schrieb:
btrfs & zfs schrieb:
hustbaer schrieb:
Denn alle 4-5 Jahre mal ne neue SSD, das sollte wohl wirklich drinnen sein.
Mit ZFS oder btrfs wüßte er, wann die SSD schlapp macht.
Soweit ich weiss tut Windows (ab Windows 7) SMART Daten auswerten und petzen wenn die Werte schlecht werden.
Smartwerte sind allerdings kein Schutz gegen Bitrods und Bitfehler.
Das können nur Dateisysteme mit einer guten Prüfsummenbildung.btrfs & zfs schrieb:
Das läuft zwar nicht auf Windows, aber man könnte ja Windows in eine VM packen, dann wäre der Unterbau mit dem die Daten gespeichert werden trotzdem ZFS oder btrfs.
Lol. Nein.
Doch! Das Dateisystem der VM wird als Datei gespeichert und diese Datei wird direkt auf ZFS bzw. btrfs gespeichert mit allen Vor- und Nachteilen von ZFS bzw. btrfs.
Wer die eigentlichen Daten nativ auf ZFS oder btrfs ablegen will, der kann diese auch als SMB Shares.
-
TyRoXx schrieb:
Es würde mich erstaunen, wenn alle "verschlüsselnden" SSDs wirksam verschlüsseln würden. Bei einem Hardware-Unternehmen frickeln doch irgendwelche Praktikanten solche zweitrangigen Werbe-Features zusammen. Da wird dann eben blockweise irgendwie mit den gleichen Schlüssel und gleichem IV "verschlüsselt". "Das wird schon keiner innerhalb der Garantie reversen und wenn doch verklagen wir den einfach". Fertig.
Die größere Gefahr besteht durch eine Backdoor die der Hersteller auf Anweisung eines Geheimdienstes in die SSDs einbauen muss.
Die Backdoor könnte einfach ein weiterer Schlüssel sein, mit dem man an den symmetrischen Key herankommt und die SSD somit ganz normal entschlüsseln kann.Deswegen habe ich weiter oben erwähnt, dass man bei SSDs eine Softwareverschlüsselung verwenden kann. Damit ist das Problem der nicht sicheren Löschbarkeit dann durchaus gelöst.
