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.
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.
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
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.
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.
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
