Gibt es ein Tool, das alle Ordner durchgeht und anhand der Daten abschätzen kann, ob sich eine Kompression lohnt oder nicht, ohne eine NTFS Kompression tatsächlich durchzuführen? Ein Ansatz für so ein Tool könnte bspw. sein zwischen den Dateitypen zu unterscheiden. Bereits komprimierte Dateien, wie bspw. PNG, ZIP, JPG usw. sind schon gut komprimiert, da ist kein nennenswerter Speicherplatzgewinn zu erwarten, aber andere Daten sind das nicht. Vielleicht gibt es auch einen anderen Ansatz das vorher abzuschätzen. Ich würde gerne gezielt herausfinden, bei welchen Ordnern meines Systems sich eine Kompression lohnen könnte.
Für ein paar Euro fünfzig gibts eine größere Festplatte. Oliver
Nano schrieb: > Vielleicht gibt es auch einen anderen Ansatz das vorher abzuschätzen. Du brauchst eine Tabelle mit empirischen Kompressionsraten zum abschätzen, die für jeden empirisch erfassten Dateityp Kompressionsraten liefert. Dann listet Du einfach die Zieldateien auf und berechnest die erwarteten komprimierten Dateigrößen. Du musst lediglich einmal Deine Tabelle mit für Dich repräsentativen Daten füttern. Dafür musst Du einmal die Dateilängen eines Laufwerks oder Ordners erheben, die Kompression anstoßen und dann die neuen Dateilängen auslesen und im Folgenden die empirischen Kompressionsraten berechnen.
Treesize? Zeigt Speicherfresser. Ganz allgemein würde ich auf zusätzliche Kompression verzichten, da es nur eine weitere Fehlerquelle darstellt!
Vor allem ist die NTFS-Kompression ein wunderbares Mittel zur Fragmentierung des Laufwerks, was die Wiederherstellungschancen bei einem Datenunfall wunderbar herabsetzt.
Nano schrieb: > Gibt es ein Tool, das alle Ordner durchgeht und anhand der Daten > abschätzen kann, ob sich eine Kompression lohnt oder nicht, ohne eine > NTFS Kompression tatsächlich durchzuführen? Dazu nimmt man einen schwachen aber auf Durchsatz optimierten Packer und komprimiert damit testweise. Zeigen sich bei einigen Dateien bei diesem durchlauf schon relativ starke Packraten geht da i.d.R. mit einem 'richtigen' Packer oder schärfer eingestellten Werten noch mehr. Da aber NTFS auch nur eines dieser auf Durchsatz optimierten Verfahren anwendet kannst du es auch gleich durch die NTFS-Komprimierung jagen. zstd ist relativ neu und hat noch höheren Durchsatz als das was NTFS verwendet, damit kannst du dann schon eine gute und schnelle Vorabschätzung machen. Wenn du dann noch entspr. Dateien ausklammerst die sowieso schon 'gepackt' sind wie jpegs,... dann geht das recht flott, je nach Datenmenge die du vorliegen hast. Der Zeitaufwand entspricht dann der Zeit als würdest du die ganzen Daten umkopieren, id.R. sogar schneller, wenn du die gepackten Versionen auf einem separaten LW ablegst gehts noch fixer, musst ja nicht jedes File aufheben, dich interessiert nur die Grösse die speicherst du ab, die gepackte Datei verwirfst du nach dem Packen.
Peter M. schrieb: > Nano schrieb: >> Vielleicht gibt es auch einen anderen Ansatz das vorher abzuschätzen. > > Du brauchst eine Tabelle mit empirischen Kompressionsraten zum > abschätzen, die für jeden empirisch erfassten Dateityp Kompressionsraten > liefert. > > Dann listet Du einfach die Zieldateien auf und berechnest die erwarteten > komprimierten Dateigrößen. > > Du musst lediglich einmal Deine Tabelle mit für Dich repräsentativen > Daten füttern. > Dafür musst Du einmal die Dateilängen eines Laufwerks oder Ordners > erheben, die Kompression anstoßen und dann die neuen Dateilängen > auslesen und im Folgenden die empirischen Kompressionsraten berechnen. Ja, so etwas könnte ich natürlich implementieren. Was mich aber noch interessiert ist, ob es ein Tool gibt, das über die Dateien drübergeht und dann im Vorfeld, ohne Schreibzugriffe, abschätzt wie gut die Datei komprimierbar ist. Das Tool könnte bspw. schauen wie viele Muster vorkommen, die dann wiederum gut komprimierbar sind. Bereits komprimierte Dateiformate könnte es natürlich im Vorfeld ignorieren, bei diesen wird nicht viel zu gewinnen sein.
oszi40 schrieb: > Treesize? Zeigt Speicherfresser. Ja, es zeigt aber auch die dicken fetten H.264 Videodateien und die sind schon komprimiert. > Ganz allgemein würde ich auf > zusätzliche Kompression verzichten, da es nur eine weitere Fehlerquelle > darstellt! Ich wollte sie nur auf die Dateien von Programmen anwenden, wenn es da einen Fehler gibt, kann ich die leicht neu installieren.
Hallo Nano, diese von Dir beschriebene Abschätzung reicht vom Aufwand her schon an die Kompression heran. Ich frage mich schon, wo da die Problemlage ist, die eine solche Lösung nahelegt, anstatt die Festplatte durch eine größere zu ersetzen. :)
Peter M. schrieb: > Vor allem ist die NTFS-Kompression ein wunderbares Mittel zur > Fragmentierung des Laufwerks, was die Wiederherstellungschancen bei > einem Datenunfall wunderbar herabsetzt. Meine eigenen Daten sind auf einer anderen Partition, wenn etwas aufgrund der Kompresion später schief laufen sollte, dann ist das nicht so schlimm. Außerdem habe ich noch Backups. Es geht eigentlich nur um die Partition bei der ich Software installieren möchte.
Nano schrieb: > Es geht eigentlich nur um die Partition bei der ich Software > installieren möchte. Ach verstehe, Du möchtest einfach nur faul sein... Ok. :) Der ganze Sums an ausführbarem Code ist doch komprimierbar (exe,dll etc) und ini-Dateien noch mehr, da reicht doch ein Mustertest per Hand an ausgewählten Exemplaren.
Tippse schrieb: > Nano schrieb: >> Gibt es ein Tool, das alle Ordner durchgeht und anhand der Daten >> abschätzen kann, ob sich eine Kompression lohnt oder nicht, ohne eine >> NTFS Kompression tatsächlich durchzuführen? > > Dazu nimmt man einen schwachen aber auf Durchsatz optimierten Packer und > komprimiert damit testweise. Zeigen sich bei einigen Dateien bei diesem > durchlauf schon relativ starke Packraten geht da i.d.R. mit einem > 'richtigen' Packer oder schärfer eingestellten Werten noch mehr. > > Da aber NTFS auch nur eines dieser auf Durchsatz optimierten Verfahren > anwendet kannst du es auch gleich durch die NTFS-Komprimierung jagen. Für beides sind Schreibzugriffe notwendig und beides ist somit nicht in der Lage, das im Vorfeld abzuschätzen. Laut Wikipedia verwendet NTFS den LZNT1 Kompressionsalgorithmus. Ich bräuchte eigentlich nur eine Software, die den LZNT1 halber, also in so einer Art Vorlauf anwendet um dann das zu erwartende Kompressionsgewinn bei der gegebenen Datei abzuschätzen, gesetzt den Fall, das man das bei diesem Algorithmus so machen könnte. Die Huffman-kodierung ermittelt bspw. zu Beginn die Häufigkeit einer Zeichenfolge, ab hier könnte man schon abschätzen, was zu erwarten ist, ohne die Kompression zu vollenden. Wenn ähnliches bei LZNT1 funktioniert, dann wäre das ein Anfang. > zstd ist relativ neu und hat noch höheren Durchsatz als das was NTFS > verwendet, damit kannst du dann schon eine gute und schnelle > Vorabschätzung machen. Ich bin mir nicht so sicher ob es eine gute Idee ist, ein anderes Kompressionsverfahren dafür zu nutzen. Einmal komprimiert das ganz anders, als bei LZNT1 zu erwarten wäre, womit die Aussagen mit Vorsicht zu genießen sind und zum anderen werde ich ohnehin die NTFS Kompression nutzen müssen, da ich ja Programmdaten komprimieren möchte. Windows muss also in der Lage sein diese bei Bedarf selber zu dekomprimieren.
Peter M. schrieb: > Nano schrieb: >> Es geht eigentlich nur um die Partition bei der ich Software >> installieren möchte. > > Ach verstehe, Du möchtest einfach nur faul sein... Ok. :) > > Der ganze Sums an ausführbarem Code ist doch komprimierbar (exe,dll etc) > und ini-Dateien noch mehr, da reicht doch ein Mustertest per Hand an > ausgewählten Exemplaren. Es geht mir mehr um die Nutzdaten der Programme. Eine EXE zu komprimieren bringt fast nichts, da die oft eh nur wenige kB groß sind. Die Leveldaten von bspw. dem Computerspiel Ark brachten aber gleich 40 GB an Ersparnis, da lohnt sich der Aufwand. Diese Dateien zu finden, das möchte ich automatisiert mit einem entsprechenden Tool erreichen.
Nano schrieb: > Es geht eigentlich nur um die Partition bei der ich Software > installieren möchte. Macht es in Hinsicht auf Performance überhaupt Sinn? Dann muss ja vor dem Laden der Programme erst noch entpackt werden. Dann doch lieber eine große Platte bzw. gleich SSD.
Nano schrieb: > und zum anderen werde ich ohnehin die NTFS Kompression nutzen müssen Kannst Du alles machen. Überlege bitte auch, wie schön DU dann fehlerhafte Daten erkennst und reparieren kannst.
Peter M. schrieb: > Ich frage mich schon, wo da die Problemlage ist, die eine solche Lösung > nahelegt, anstatt die Festplatte durch eine größere zu ersetzen. :) Das ist geplant, es wird allerdings eine M.2 SSD. Bis dahin wollte ich bei meiner Programmpartition durch entsprechendes Dateimanagement mir etwas Platz verschaffen.
Karl schrieb: > Nano schrieb: >> Es geht eigentlich nur um die Partition bei der ich Software >> installieren möchte. > > Macht es in Hinsicht auf Performance überhaupt Sinn? Dann muss ja vor > dem Laden der Programme erst noch entpackt werden. Dann doch lieber eine > große Platte bzw. gleich SSD. Ja, das macht Sinn. Weil die CPU bei diesem leichtgewichtigen Kompressionsverfahren die Daten schneller entpacken kann, als die Festplatte oder SSD die Daten liefern kann. Ob's bei einer M.2 SSD anders aussieht, die kann die Daten ja deutlich schneller liefern, müsste man mal messen.
Karl schrieb: > > Macht es in Hinsicht auf Performance überhaupt Sinn? Dann muss ja vor > dem Laden der Programme erst noch entpackt werden. Dann doch lieber eine > große Platte bzw. gleich SSD. Natürlich macht das Sinn - schau Dir mal ZFS an! Das setzt natürlich einen über Windows hinausgehenden Horizont voraus
Naja, er will ja nur abschätzen. Ich schätze mal.... ca. 1/3 der ursprünglichen größe. Wer schätzt mit?
Hallo oszi40, oszi40 schrieb: > Kannst Du alles machen. Überlege bitte auch, wie schön DU dann > fehlerhafte Daten erkennst und reparieren kannst. wie reparierst Du fehlerhafte Daten?
Thomas schrieb: > Naja, er will ja nur abschätzen. > > Ich schätze mal.... ca. 1/3 der ursprünglichen größe. > > Wer schätzt mit? Du sollst auch die Dateien und Ordner benennen. Abzuschätzen was eine Kompression kann, ist keine Leistung, das ist bekannt.
Von der Statistik her werden wohl die meisten Platzfresser schon komprimiert herumliegen? Instatllationsprogramme sind auch oft gepackt. Die paar .txt könnten zwar auf 10% komprimiert werden, wird aber gegenüber komprimierten Videos kaum Platzgewinn erreichen, sondern eher Zeit kosten. Meine Meinung weiterhin: Aufwand>Nutzen. Größere Platte beschaffen und Image machen. Alte Platte als Backup in den Schrank legen.
Nano schrieb: > Ein Ansatz für so ein Tool könnte bspw. sein zwischen den Dateitypen zu > unterscheiden. > Bereits komprimierte Dateien, wie bspw. PNG, ZIP, JPG usw. sind schon > gut komprimiert, da ist kein nennenswerter Speicherplatzgewinn zu > erwarten, aber andere Daten sind das nicht. Eion fertiges Tool kenne ich nicht, ist mit C# aber recht schnell selbst erstellt. Einfach die Verzeichnisse rekursiv durchgehen und die Dateigröße der betreffenden Dateien aufsummieren. Dabei Dateien, die kleiner als die Blockgröße des Filesystems sind, ggf. nicht berücksichtigen. Ansatz z.B. hier: https://docs.microsoft.com/en-us/dotnet/api/system.io.directory.getfiles?view=netframework-4.8
oszi40 schrieb: > Meine Meinung weiterhin: Aufwand>Nutzen. Am Ark Beispiel sieht man ja, dass der Nutzen groß sein kann. 40 GB kriegt man auch mit der günstigsten SSD nicht für lau. Und den Aufwand möglichst gering zu halten, darüber handelt ja der Thread. Wenn man die Daten nicht Testkomprimieren muss, weil man einen Weg gefunden hat, das im Vorfeld abzuschätzen, dann hat man schon einmal den Aufwand verringert, ebenso, wenn man bereits komprimierte Dateien und Ordner herausfiltert. Aber ich sehe schon, dass noch kein Tool genannt wurde zeigt, dass es wohl keines gibt und ich da etwas selber programmieren muss.
Einfachste Lösung: 1. Besorgt Dir eine USB-Platte. 2. Formatiere sie NTFS komprimiert. 3. Schiebe die Daten darauf, von denen Du wissen willst, wie gut sie sich komprimieren lassen. 4. Profit.
:
Bearbeitet durch User
Nano schrieb: > ich ohnehin die NTFS Kompression nutzen müssen, da ich ja Programmdaten > komprimieren möchte. Ja eben, merkst du was? Dein Vorhanben ist wie "wasch mir den Pelz aber mach mich nicht nass". Wenn du genaue Abschätzungen haben willst musst du es durch die NTFS-Komprimierung jagen, also ist dein Vorhaben Unsinn je genauer die Abschätzung werden soll und kannst gleich alles komprimieren, mit nem groben Dateitypfilter der Files wie zip, rar, png,... auslässt.
Ich finde die Frage, wieviel das überhaupt bringt, durchaus berechtigt, bevor ich irgendwelche Modifikationen an meiner Systempartition vornehme.
Berufsberater schrieb: > Nano schrieb: >> ich ohnehin die NTFS Kompression nutzen müssen, da ich ja Programmdaten >> komprimieren möchte. > > Ja eben, merkst du was? Dein Vorhanben ist wie "wasch mir den Pelz aber > mach mich nicht nass". Wenn du genaue Abschätzungen haben willst musst > du es durch die NTFS-Komprimierung jagen, also ist dein Vorhaben Unsinn > je genauer die Abschätzung werden soll und kannst gleich alles > komprimieren, mit nem groben Dateitypfilter der Files wie zip, rar, > png,... auslässt. Oben habe ich alles Dau gerecht erklärt, es ist nicht schlimm, wenn man am Anfang Rückfragen hat, aber wenn man dann immer noch nicht verstanden hat, worum es eigentlich geht, dann sollte man besser Schweigen, anstatt so ganz arrogant auf Stammtischniveau Sätze wie "Merkst du was" rauszuhauen. Man sieht jedenfalls, dass du von Algorithmen, Programmieren und Computer nicht viel Ahnung haben kannst, deswegen halt Stammtischniveau mit Halbwissen. Ich erkläre dir daher das, was ich oben schon gesagt habe, also jetzt extra für dich zum n-ten mal: Es geht um folgendes. Wenn du 1000 Einsen als Folge hast, dann musst du da keinen Kompressionsalgorithmus vollständig drüberlaufen lassen um zu wissen, dass das gut komprimierbar ist, das siehst du schon so im Anfangsdurchlauf. Das gleiche bei einem Textstring wie "HalloHalloHallo", das Wort kommt dreimal vor, also wird man es gut komprimieren können. Ein Kompressionsalgorithmus ist keine atomic Operation, okay, das weißt du wahrscheinlich wieder nicht, was das in der Informatik bedeutet, also muss ich länger ausholen. Es bedeutet im Prinzip, das bspw. aus A B wird und das vollständig und wenn der Prozess nicht abgeschlossen werden konnte, das alles wieder zurückgerollt oder verworfen wird. Ein Kompressionsalgorithmus besteht aus mehreren Schritten, nennen wir sie mal 1, 2, 3, 4, 5 bis n und um zu wissen, ob etwas gut Komprimierbar ist, muss man nicht alles vollständig bis Schritt n durchlaufen lassen, wie du mit deinem Halbwisen behauptest, sondern du kannst je nach Algorithmus bei 1 oder 2 schon abbrechen und damit sparst du sehr viel Rechenzeit. Um also mal dein Pelz Beispiel zu bleiben. Es sei gegeben zwei Bären. Bär A hat sich im Dreck gewälzt. Bär B hat sich nicht im Dreck gewälzt. Von uns beiden bisst du jetzt derjenige, der den Eimer nimmt und für Bär A und Bär B eine vollständige Wäsche mit schruppen, viel Wasser und allem macht. Ich dagegen schau mir erstmal nur den Pelz von A und B an. A wasche ich mit Wasser, den Bär mach ich nass, weil ich sehe, dass der Pelz dreckig ist. Beim Bär B breche ich nach dem anschauen des Pelzes ab, da komme ich erst gar nicht zum Schritt "Bär waschen", denn der Bär ist sauber. Und so wie es da ist, so kann man das auch mit Daten machen. Oben habe ich z.B. gesagt, man kann alle Dateien die ein Dateiformat haben, das selbst schon komprimiert, ignorieren kann. Auch dieses Ansehen, "ist Datei bild.jpg im JPEG Format?" ist schon ein Schritt, der Schritt ist zwar nicht Teil eines Kompressionsalgorithmus, aber er könnte sehr wohl Teil eines Programmes sein, dass die Dateien nach deren Kompriebnierbarkeit zusammensucht. Nach dem klar ist, dass man es nicht weiter zu untersuchen braucht, wird für diese Datei jeder weitere folgende Schritt abgebrochen. Bei eine Datei unbekannten Dateityps könnte man dann einen groben "Gucken" drüberlauf machen, was dem obigen Beispiel für den Gedachten Kompressionsalgorithmus nicht 1 bis Schritt n ist, sondern eben vielleicht nur bis Schritt 2. Soviel zu diesem Punkt. Und was den Satz betrifft, den du von mir zitiert hast, geht es bei dem um einen ganz anderen Kontext, nämlich das was ganz am Schluss, nach dem Durchchecken kommen muss, nämlich dass, wenn Komprimiert werden muss, wegen NTFS, sowieso die Kompression von NTFS benutzt werden muss. Also bist du mit deiner arroganten Antwort "Merkst du was" auf dem völlig falschen Dampfer und merkst es nicht einmal.
Walter T. schrieb: > bevor ich irgendwelche Modifikationen an meiner Systempartition > vornehme. Um einzelne Dateien in einem NTFS-Filesystem zu komprimieren brauchst du an deiner Systempartition überhaupt nichts dran rumzumodifizieren. Das ganze kann gezielt pro Datei oder Verzeichnis jederzeit ein und ausgeschaltet werden.
Soweit ich weiß, ist die NTFS-Kompression sowohl vom Algorithmus als auch von der Performanz her nichts besonderes, da diese sicherlich auf Verlässlichkeit und Datenintegrität optimiert ist und damit nur durchschnittlich schnell sein dürfte. Ich meine, in einem Blogartikel von Raymond Chen (Microsoft Windows-Entwickler) mal etwas zu dem Thema gelesen zu haben, ist aber schon eine Weile her. Das würde zumindest auch erklären, warum man u.a. bei ReFS darauf verzichtet hat. Ich wüsste auch nicht, warum man aktiv genutzte lokale Dateien in der heutigen Zeit komprimieren sollte. Vor allem, wenn diese eine gewisse Größe erreichen (GB+), denn dann kommt für jeden Lesezugriff auch immer der CPU-Overhead für die Dekompression ins Spiel. Caches und RAM sind hier die Grenze, werden viele Daten nachgeladen und müssen andere dafür aufgrund mangelndem Speicher wieder freigegeben werden wirkt sich das sicherlich auf die Geschwindigkeit aus. Bei vielen Schreibzugriffen macht es noch weniger Sinn. Ich halte von der NTFS-Kompression nicht viel, die taugt allenfalls für Archivierungszwecke selten genutzer Dateien.
FS schrieb: > Ich wüsste > auch nicht, warum man aktiv genutzte lokale Dateien in der heutigen Zeit > komprimieren sollte. Vor allem, wenn diese eine gewisse Größe erreichen > (GB+), denn dann kommt für jeden Lesezugriff auch immer der CPU-Overhead > für die Dekompression ins Spiel. Caches und RAM sind hier die Grenze, > werden viele Daten nachgeladen und müssen andere dafür aufgrund > mangelndem Speicher wieder freigegeben werden wirkt sich das sicherlich > auf die Geschwindigkeit aus. Eine Festplatte ist im Laden der Daten langsamer, als sie eine moderne CPU dekomprimieren kann. Da reicht schon ein grober Blick auf den Datendurchsatz einer Festplatte und ein Vergleich mit der Bandbreite des RAM. Eine 4 TB Festplatte schafft vielleicht etwa 200 MB/s (so als Richtwert, hab's nicht gemessen) Die Bandbreite des RAMs liegt bei DDR4-2133 RAM bei 17 GB/s im single Channel Betrieb. Im Vergleich zur CPU ist RAM aber unglaublich langsam, weswegen man der CPU heutzutage mehrere Caches verpasst. Wenn man jetzt weiß, dass eine CPU + Cache um ein vielfaches schneller ist, als Zugriffe auf das RAM, dann kann man auch als grobe Überschlagsrechnung die Annahme treffen, dass sie bei einfachen Kompressionsalgorithmen, wie sie bei NTFS verwendet werden, wesentlich schneller die Daten komprimieren und dekomprimieren kann, als der Controller der Festplatte die Daten von der Festplatte holen und ins RAM schieben kann. Denn das Nadelöhr ist hier ganz klar die Festplatte. Wenn die Daten komprimiert vorliegen, dann geht theoretisch das Laden mit Kompression sogar schneller, weil dann die Festplatte nicht so viele Daten pro Sekunde zum RAM schieben muss. Und die Praxis zeigt dann auch, dass da kaum ein Unterschied besteht. Wobei bei diesem Test eine SSD verwendet wurde, deren Datendurchsatz ist deutlich höher als die einer Festplatte, so dass sich das, wie bereits gesagt, zugunsten der nicht Kompression etwas verschiebt, aber die Unterschiede sind bei einer SATA SSD vernachlässigbar klein: https://www.tomshardware.com/reviews/ssd-ntfs-compression,3073-10.html Und hier gibt es noch eine weitere Erklärung dazu: https://superuser.com/questions/411720/how-does-ntfs-compression-affect-performance Lediglich mit M.2 NVME SSDs kann es wieder anders aussehen, da diese sehr schnell Daten laden und ins RAM schieben kann. > Ich halte von der NTFS-Kompression nicht viel, die taugt allenfalls für > Archivierungszwecke selten genutzer Dateien. Bei mir hat sie viel gebracht, siehe oben die Beispiele. Und gerade bei Spielen, bei denen die Map nur einmal am Anfang ins RAM geladen werden muss, merkt man beim Spielen nichts mehr, denn die Daten sind dann ja schon lange im RAM. Aber es muss halt jeder selber wissen ob er die Kompression nutzen möchte oder nicht. Die NTFS Kompression kann man übrigens gezielt auf Dateien und Ordner anwenden, d.h. es ist kein alles oder nichts, sondern man kann ganz gezielt auswählen, was man komprimieren möchte und was nicht. Ich mache das z.B. genau so. Mein Windows Ordner ist bspw. komplett unkomprimiert, während der obige Ark Daten Ordner komprimiert ist und dessen EXE und DLL Dateien wiederum nicht. Und damit ist auch klar, warum ich den Thread gestartet habe, mir geht es darum, gezielt die Ordner herauszufinden, wo es sich lohnt und der Aufwand es wert ist. Wenn ich Speicherplatz im zweistelligen GB Bereich spare, dann nutze ich die Kompression auf einen Ordner jedenfalls gerne.
Nano, Du hast Dich gut mit dem Thema Komprimierung beschäftigt. Es stimmt natürlich, daß eine komprimierte Datenmenge schneller durch einen Flaschenhals gelangt. Mir wäre Rosinenpickerei zu mühsam und das Risiko dabei einen Fehler zu machen, etwas zu hoch. Nano schrieb: > 40 GB kriegt man auch mit der günstigsten SSD nicht für lau. 1 TB heute ca. <120€ https://www.idealo.de/preisvergleich/OffersOfProduct/6220699_-ssd-plus-1tb-sandisk.html
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.