SSD Haltbarkeit bei Einsatz als Build-System
-
Fortsetzung zu https://www.c-plusplus.net/forum/343331
Inwieweit ist es sinnvoll eine SSD (statt HDD) als Laufwerk für Software-Builds zu nehmen.
Inwieweit kann ich die Haltbarkeit der SSD abschätzen?
Auf was (Technik der SSD SLC vs MLC etc) sollte ich achten?Ein typischer Build (das meiste davon MS VisualStudio, C++) dauert bei uns ca. 30 min, erzeugt ca. 10GB Daten und 5k Dateien.
Ich nehme an da wird es noch deutlich mehr an temporären Dateien geben. (kann ich schlecht abschätzen, vielleicht weiss das jemand?)
Dazu kommen noch so sachen wie der MSVC IntelliSource- oder VAssist-cache etc.
Dann gibt's noch Tests, die auch recht schreib-intensiv sind. (ca. 30GB, 20k Dateien)Gehen wir von ein paar Builds pro Tag aus. (meistens jedoch inkrmentell)
Also, ist eine SSD eine gute Idee für so ein Build-/Test-System oder komme ich schnell an Haltbarkeitsgrenzen?
-
scrontch schrieb:
Ein typischer Build (das meiste davon MS VisualStudio, C++) dauert bei uns ca. 30 min, erzeugt ca. 10GB Daten und 5k Dateien.
scrontch schrieb:
Dazu kommen noch so sachen wie der MSVC IntelliSource- oder VAssist-cache etc.
Dann gibt's noch Tests, die auch recht schreib-intensiv sind. (ca. 30GB, 20k Dateien)Das ist jetzt nicht gerade viel.
Sich über so etwas Gedanken zu machen ist teurer als alle paar Jahre mal ein neues SSD zu kaufen. Die verschwendete Zeit mit einem HDD kommt vermutlich auch nicht günstig.
-
vermutlich, ja.
Aber ich muss es irgendwie abschätzen um dem Chef schmackhaft zu machen.
Es geht unter den Kollegen das Gerücht um dass die SSD nur nen paar Monate halten würde bei den vielen Wrties.
-
Einfache SSDs ohne Schnickschnack halten so Größenordnung 1 PB aus. Wenn ein SSD sehr früh kaputtgeht, hat das andere Ursachen. Fertigungsfehler gibt es bei HDDs aber auch oft.
Angenommen dein Build schreibt 50 GB und der wird 10 mal am Tag ausgeführt. Das macht 500 GB am Tag. Nach 2000 Tagen wäre 1 PB erreicht.
-
scrontch schrieb:
Fortsetzung zu https://www.c-plusplus.net/forum/343331
Inwieweit ist es sinnvoll eine SSD (statt HDD) als Laufwerk für Software-Builds zu nehmen.
Ist beim Build die Festplatte der limitierende Faktor, dann macht es Sinn.
Inwieweit kann ich die Haltbarkeit der SSD abschätzen?
Die Anzahl der durchschnittlichen Schreibzyklen geben die Hersteller an, das kann man hochrechnen mit wie viel TB an Daten man die Platte beschreiben muss, damit sie nach x Jahren mit einer gewissen Wahrscheinlichkeit nicht mehr zuverlässig ist.
Auf was (Technik der SSD SLC vs MLC etc) sollte ich achten?
Auf ein Dateisystem, dass sich nicht auf den Datenträger verlässt und dir somit auch sagen kann, dass die Daten fehlerhaft sind.
In Frage käme hier z.b. btrfs oder ZFS.
EXT4, NTFS und Co können das alle nicht, die verlassen sich auf den Datenträger und wenn der meldet es ist alles okay, auch bei einem einfachen bitflip, dann ist scheinbar alles okay, ist es aber nicht.
Ein typischer Build (das meiste davon MS VisualStudio, C++) dauert bei uns ca. 30 min, erzeugt ca. 10GB Daten und 5k Dateien.
Ich nehme an da wird es noch deutlich mehr an temporären Dateien geben. (kann ich schlecht abschätzen, vielleicht weiss das jemand?)Anzahl Quellcodedateien * Objektdateien + das Zeugs was das Buildsystem anlegt + die Exe die rauskommt = Anzahl der neu erstellten Dateien.
-
btrfs & zfs schrieb:
Auf was (Technik der SSD SLC vs MLC etc) sollte ich achten?
Auf ein Dateisystem, dass sich nicht auf den Datenträger verlässt und dir somit auch sagen kann, dass die Daten fehlerhaft sind.
In Frage käme hier z.b. btrfs oder ZFS.
EXT4, NTFS und Co können das alle nicht, die verlassen sich auf den Datenträger und wenn der meldet es ist alles okay, auch bei einem einfachen bitflip, dann ist scheinbar alles okay, ist es aber nicht.
Das halt ich für halbwegs paranoid. Klar hast du theoretisch Recht. Praktisch ist es aber quasi kein Problem. Du hast (sehr sehr) gutes ECC in aktuellen SSD Controllern und Prüfsummen bei der Übertragung über SATA.
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.
Bei Festplatten würde ich die Sache etwas anders beurteilen. Die sollten zwar theoretisch auch gutes ECC haben, und vielleicht ist das bei den 4K Platten auch wirklich besser. Bei 512B Sektor HDDs gibt es allerdings gute Daten die dagegen sprechen dass HDDs sehr zuverlässige Fehlererkennung hätten. Wobei sich auch hier die Fehlerrate in einem Bereich abspielt wo es für ne Buildmaschine vermutlich egal wäre.
-
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
