SSD Haltbarkeit bei Einsatz als Build-System
-
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.
-
btrfs & zfs schrieb:
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.
Mein "nein" ist als "nein, das will man wirklich nicht machen" zu verstehen. Auf nem Build System hast du keine FS-Performance zu verschenken. Ja, man kann virtualisierten Storage schnell hinbekommen, vermutlich sogar wenn ZFS/... die Basis ist. Aber das kostet. Wenn du einfach nur einen einzelnen Hobel mit einer SSD drinnen hast und da der Storage, der Hypervisor und der Build-Server als Guest drauf rennt, dann hab ich echt Bedenken als FS für die VHD Files etwas herzunehmen was Prüfsummen über alle Datenblöcke rechnet.
Und BTW: Du hast auch nicht alle Vorteile von ZFS/btrfs. ZFS z.B. verwaltet seine Verzeichnisstrukturen sehr "vorsichtig", so dass z.B. der Impact eines korrupten Blocks möglichst minimiert wird. Dadurch wird quasi nie die komplette Partition durch einen oder zwei Blockfehler unbrauchbar. Bei NTFS dagegen kann dir das passieren. Und da hilft auch nicht dass die Blöcke in denen NTFS seine Verzeichnisstrukturen speichert in einem ZFS File stehen.
