Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Ich habe von der USB-HDD auf die USB-HDD kopiert, um damit ein Backup mit Robocopy oder einem anderen Tool zu simulieren. Selbst wenn ich ein Tool verwenden würde, welches nur große Imagedateien erstellt, wüsste ich nicht, mit welcher Paketgröße dieses die Dateien beschreibt. Da ich noch nicht weiß, ob es überhaupt eine sinnvolles Backupprogramm gibt, sollte die USB-HDD auch dafür geeignet sein, dass viele einzelne Dateien, große wie kleine geschrieben werden.
Da ich noch nicht weiß, ob es überhaupt eine sinnvolles Backupprogramm gibt, sollte die USB-HDD auch dafür geeignet sein, dass viele einzelne Dateien, große wie kleine geschrieben werden.
Das ist kein Problem dieser HDD oder HDDs im allgemeinen. Das ist halt einfach so, daran kannst du direkt auch nichts ändern, sondern nur das Problem umgehen, indem du nicht viele kleine Dateien kopierst.
Ja klar kann man die selber bauen.Dann bremsen aber oft die verbauten Controller aus,wenn man diese Standard billig gehäuse kauft.Bin mir nichtmal sicher, ob es da nicht sogar ein Limit von der Speichergröße gibt.
Mal davon abgesehen,das nur wenige dazu bereit sein dürften über 6152 Euro auszugeben
Man kann keine Backups "von der HDD auf die HDD" machen, dazu benötigt man mindestens zwei voneinander unabhängige Datenträger. Und wenn du's wirklich so machst, geht ja alles doppelt über die selbe Schnittstellt! Und die selben Datenträger u. Controller!
Selbst wenn ich ein Tool verwenden würde, welches nur große Imagedateien erstellt, wüsste ich nicht, mit welcher Paketgröße dieses die Dateien beschreibt.
Was relativ unwichtig ist. Wenn Du 100k Dateien kopierst, dann werden diese Datei für Datei (oder bei passender SW auch parallel, was aber bei einer HDD nur bedingt hilft) an der Quelle geöffnet, am Ziel die Daten und der Directoryeintrag geschrieben und danach an der Quelle die nächste Datei geöffnet. Bei einem ext. Laufwerk findet das Schreiben u.U. ohne Cache statt, sprich das OS warte mit dem Lesen der nächsten Datei, bis das Laufwerk das reale Schreiben der vorherigen Datei auf das Speichemedium bestätigt.
Das sind also mal eben 200k Directoryeinträge zu 2 Einträgen, die das OS behandeln muss. Jeweils plus die Nutzdaten aus den Dateien.
Beim Kopieren von 100k kleiner Dateien von SSD auf Ramdisk (beides NTFS) schaffe ich gerade mal 25 MB/s. Auch mit einer besseren Ramdisk-SW wären das keine 300-1500 MB/s drin, die ich bei großen Datei problemlos erreiche.
eYc schrieb:
Und wenn du's wirklich so machst, geht ja alles doppelt über die selbe Schnittstellt! Und die selben Datenträger u. Controller!
Es würde vor allem die selbe HDD Kopf-Mechanik genutzt. Selbst, wenn die komplette FAT der Quelldaten im Ram liegen sollte, werden dabei 100k Nutzdaten gelesen und 100k Nutzdaten geschreiben sowie 100k neue FAT-Einträge. Alle drei Operationen pro Datei potentiell an unterschiedlichen Stellen der HDD, selbst wenn keine Datei fragmentiert sein sollte. So "Kleinigkeiten" wie SMR und das USB-Protokoll kommen noch oben drauf.
Da die Platte SMR hat bleibt eigentlich nur die Schreibzugriffe groß halten, oder eine andere Platte finden die kein SMR hat.
Wenn man die Schreibzugriffe groß und einigermaßen sequentiell hält sind SMR platten auch nicht langsam. So aus dem Bauch heraus sind Dateien < 1 MB böse, ein paar < 20 MB ok, aber am besten hält man es im Bereich jenseits 128 MB. Backup mit schneller Kompression als ganzes Archiv draufschieben sollte gut gehen.
Was ich allerdings gerade mal wieder feststellen musste ist dass NTFS eher suboptimal ist um wirklich sequentiell und unfragmentiert zu schreiben. Wenn da häufiger Backups drauf geschrieben und wieder gelöscht werden könnte es sich lohnen ein anderes Dateisystem zu nehmen. Etwas das neue Dateien eher am Stück schreibt und nicht in jede kleine Lücke quetscht die irgendwo zu finden war. Defragmentieren dürfte da auch nicht besonders schnell sein und ohne muss man ggf. noch mehr darauf achten wie man darauf schreibt.
Da windows nicht besonders offen ist für andere Formate ist bleibt da nicht viel übrig wenn man die Platte direkt mit Windows beschreiben will :/
Eine SSD fürs Backup nutzen sollte allerdings schon arg Leidensdruck bei der Geschwindigkeit vorraussetzen. Oder man hat einfach nicht viel zu Sichern, kleine HDDs sind auch eher unpraktisch.
Welche Backupsoftware würde denn dafür sorgen, dass nicht in Minihäppchen auf den Datenträger geschrieben würde? Ich habe noch von keiner Software gelesen, dass sie diesbzgl. optimiert wäre. Selbst solche Software wie Acronis TIH, die nur große Archive erstellt, schreibt diese in mehr oder weniger großen Häppchen.
Und welches Filesystem wäre besser geeignet? NTFs habe ich verwendet, um große Dateien schreiben und möglichst hohe Kompatibilität zu haben.
Welches Filesystem wäre nicht exotisch, von Linux unterstützt und trotzdem geeignet (zuverlässig, sicher und schnell)? Wenn es so etwas gibt, könnte ich die Sachen übers Netzwerk an Linux schicken, welches diese dann auf die Platte packt.
Ich habe mir nun eine WD Elements 8TB besorgt, in der laut GSmartControl eine WD80EMZZ mit 5640 rpm werkelt. Im Leistungstest von Linux Mint zeigt sie auch nach großen Kopieraktionen nicht den typischen Leistungseinbruch einer SMR-HDD ein. Das Kopieren des ursprünglichen Testordners (innerhalb der USB-HDD) mit 14 GB und 120.000 Dateien lief mit 8 MB/s, also mehr als 10 x so schnell wie bei der SMR-HDD.
Das ist schon mal deutlich angenehmer und bei der Kapazität nicht vollkommen unpraktikabel, falls es durch das Backupprogramm selbst oder durch äußere Umstände, wie z.B. Multitasking verursacht, zu häufigeren Zugriffen kommt.
Mir kam noch die Idee, den Kopiervorgang mit ext4 statt nur mit ntfs zu machen. Ich habe dazu die bestehende ntfs-Partition auf ~300 GB verkleinert und dahinter einer ext4-Partition mit ~300GB angelegt. Physikalisch liegen beide Partitionen in einem Bereich, in dem der Geschwindigkeitsunterschied nicht groß ist.
Das Ergebnis hat mich sehr überrascht. Ich habe den o.g. Ordner (14 GB, 120.000 Objekte) von der ntfs-Partition auf die ext4-Partition kopiert, was mit 35 MB/s gelaufen ist.
Dann habe ich diesen Ordner innerhalb der gleichen ext4-Partition kopiert, was mit 59 MB/s gelaufen ist.
Bei der Dateigröße und mit HDD bleiben kaum noch Wünsche offen. Damit kann ich sehr gut leben.
Ich habe mir nun eine WD Elements 8TB besorgt, in der laut GSmartControl eine WD80EMZZ mit 5640 rpm werkelt. Im Leistungstest von Linux Mint zeigt sie auch nach großen Kopieraktionen nicht den typischen Leistungseinbruch einer SMR-HDD ein.
Das ist für mich auch nicht unbedingt ein Wunder, da ich für die Platte eher auf CMR tippen würde. Es gibt die white label halt nicht einzeln und Google findet auf Anhieb auch nicht viel Info dazu.
Dass Du vorher Linux für NTFS Performancetests genutzt hattest. hatte ich glatt übersehen. Das war hoffentlich mit einem Kernel 5.15 oder neuer, um nicht den alten, bekannt langsamen User-Space NTFS-3G Treiber zu nutzen.
Die Kopiertests mit ntfs liefen mit Kernel 5.4 und 5.13.
Dass ntfs damit besonders lahm wäre, ist mir bisher noch nicht aufgefallen. Ich habe es allerdings zuvor auch nie gemessen, sondern nur im Alltag benutzt.
Zwischen "besonders lahm" und langsamer wie unter Windows und ext4, gibt es anscheinend Unterschiede.
Je nachdem, wie die Leute NTFS-3G und NTFS3 testen, kommen recht unterschiedliche Ergebnisse raus. Ohne mir den Benchmark anzuschauen würde ich sowas aber eher mit Deinen Teste vergleichen wie Benchmarks zum Lesen großer Dateien: https://openbenchmarking.org/result/2009092-NE-NTFSCOMPA56
Ich meine, ich schrieb es hier schon: Bisher ist mir nicht aufgefallen, dass ntfs-3G besonders lahm wäre. Ich habe jetzt mal eine große Datei auf der gleichen HDD kopiert und komme auf rund 90 MB/s. Lediglich bei den vielen kleinen Dateien hinkt es stark hinterher. Der Test bei bitblokes (warum wird auf vielen Seiten kein Datum angegeben?) scheint ziemlich betagt zu sein, da die Kernel 2.6 benutzen. In der Zwischenzeit ist AFAIK auch viel an ntfs-3G geschraubt worden.
Die Tage von ntfs-3G dürften gezählt sein, da Linux Mint mWn. ab Kernel 5.15 einen anderen Treiber verwendet.
