USB-Festplatte 2,5 Zoll mit SMR und 4Kn-Sektoren gesucht.

Anzeige

Der Performanceeinbruch den du berichtest läßt sich doch in keinem Fall alleine mit sowas erklären.

Du wirst in dem Bereich gelandet sein, wo die Shingle sich regenerieren muss und es hat genau gar nichts mit 512 und 4k zu tun.

Deine Partition wird ja wohl im Alignment sein, oder etwa nicht? Also einfach erste Partition bei 1MB beginnen lassen, damit auch möglichst viele Faktoren weg sind. Mach man doch seitdem es SSD gibt so. Selbst wenn du die übelsten Performanceprobleme hättest, selbst Alignmentproblem und zuerst lesen und dann den ganzen Block schreiben ... nein. Das haut nicht hin. Nicht bei sequentiellem Schreiben.

Will sagen: egal was für eine Shingle du kaufst, du wirst immer das Shinlge-Problem bekommen, sobald du zuviel Backup auf einmal schreibst.

Nein.

Du redest vom Lesen, ich vom Schreiben. Was du meinst sind inkrementielle Backups auf Diskebene. Was du dann schreibst, sind eben diese Veränderungen. Aber du schreibst sie nicht in einem bestehenden File, das nur reserviert wurde, du schreibst sie als "größeres" File und zwar zusammenhängend auf deinen Backupdatenträger und nicht als random access. Wenn du direkt in das Backup hineinschreiben würdest auf Low-Level im Backupfile, würdest du ja dein Backup gefährden. Das geht schon eher in den Bereich Raid 1:1 Kopie und nicht Backup sowas.

Was ich theoretisiert hatte, war ein Szenario, wo ein File reserviert wurde, ähnlich wie ein Swapfile, und nicht sequentiell und am besten ohne Alignment wild durcheinander halbe Blöcke geschrieben werden. Und das natürlich ohne Cache, damit auch ja nichts opitmiert werden kann. Sowas macht aber doch keiner der bei Verstand ist ohne Notwendigkeit. Und für ein Backup ist das nicht notwendig. Meine Soft schreibt zwar "kleine" Files, aber selbst diese kleinen Files sind immer noch um Faktor 50-100 größer als die läppischen 4kb.

Nochmal langsam: Ein guter Backupprozess mag lesen wie er will, aber geschrieben wird sequentiell. Und bei sequentiellem Schreiben ist jeglicher Einfluss von Shingle und Alignment und Sektorgröße ... nicht in der Größenordnung, wie du es beschreibst. Das ist ja schon fast Stillstand, mit deinen 100Kbit.

Allerdings kann es durchaus sein, dass deine beiden Backuprogramme für random write optimiert wurden. Wo Shingles nunmal abstinken.

Was passiert, wenn die Platte einige Stunden am PC hängt und nichts tut und du dann ein paar GB manuell rüber schiebst? Bricht das ein? Ist das schnell?

 

Ich könnte auch neue, größere HDDs gut gebrauchen, aber mittlerweile sind die sehr teuer geworden, vor allem 14 TB u. 16 TB, von 18 TB will ich erst gar nicht schreiben. Mal schauen, wie sich das mit Chia weiter entwickelt ...

Ich hatte mal gelesen, dass ab 10 TB, auf jeden Fall wohl ab 12 TB es sich eigentlich immer um CMR handeln soll. Darunter ist wohl meistens fraglich.

 

Habe ich auch nirgends behauptet, es wird ziemlich sicher eine Kombination aus Shingle-Murks und 512e-Mapping sein. Am Shingle-Murks kann man bei externen 2,5 Zoll USB-Festplatten aber nun mal kaum etwas ändern, also rückt 512e in den Fokus. Das ist bei aktuellen OS ein komplett unnötiges Mapping, also ist die Wahrscheinlichkeit hoch, dass es auch Platten ohne dieses Mapping geben sollte. CMR mit 4Kn habe ich ja selbst schon seit Jahren, also liegt es nahe, sich nach SMR 4Kn zu erkundigen.

Blöd nur, dass das nicht zu dem beobachteten I/O-Verhalten passt, in dem es praktisch keine großen Bursts gibt, die die Nutzung eines Media Caches erklären würden. Stattdessen gibt es nur durchgängig sehr niedrige Schreib-/Leseraten mit vereinzelten kleinere Einbrüchen, vonwegen eh schon niedriges Niveau, in denen die Latenzen dann kurzzeitig deutlich höher sind. DIESE Zeiten könnten interne Reorganisation sein, das erklärt aber nun mal nicht die durchgängig niedrige Leistung.

Ja, das habe ich auch schon längst geschrieben. Das kommt aber davon, wenn Leute schreiben, die konkrete Fragen eigentlich gar nicht beantworten können... :-/

Es wird überhaupt nicht durchgängig sequentiell geschrieben, vonwegen Windows+NTFS+VSS. Das bedeutet, dass unabhängig von den rein zu sichernden Daten IMMER zusätzliche Schreiblast durch VSS anliegt und es damit konkurrierendes, in aller Regel mindestens etwas Random I/O gibt. Der Punkt ist, dass man darauf keinerlei Einfluss hat und es bei anderen Platten aber nun mal auch kein so großes Problem ist.

So lange die Platte schnell genug ist, sind prinzipielle Einbrüche nebensächlich. Und genau das ist der Punkt: Manche Leuten haben mit ihren SMR-Platten KEINE so starken Leistungseinbrüche und das muss ja an irgendwas liegen.

Doch und sollte mittlerweile auch ziemlich klar gemacht haben, dass ich solche Dinge besser weiß.

Nein, ich rede vom Lesen und Schreiben wegen differentieller Backups.

Das stimmt natürlich einfach nicht, du kennst ganz offensichtlich Konzepte wie Snapshots einfach nicht und weißt nicht, wie WBADMIN arbeitet. In solchen Fällen garantieren Snapshots den Zustand einer Datei zum Zeitpunkt X und der Witz daran ist, dass man genau WEGEN der Snapshots vorhandene Daten beliebig überschreiben kann. VSS kopiert die zu überschreibenden Daten einfach vorher an eine anderen Stelle und so muss man eben gerade nicht komplette Dateien neu schreiben. Einfach mal überlegen, wie sonst z.B. große VM-Dateien mit hunderten GiB Größe effizient gesichert werden sollten, wenn sich in den Dateien nur wenige MiB an Daten geändert haben. Mit dem von mir beschriebenen Vorgehen geht das effizient, mit deinem und der Erstellung neuer Dateien eben nicht.

Copy-On-Write – Wikipedia
Copy-on-write - Wikipedia
Volume Shadow Copy Service

Differenzielle Backups mit Snapshots schreiben Dateien aber nun mal nicht komplett sequentiell neu, weil das absurde Platzverschwendung wäre. Gleichzeitig werden trotzdem natürlich größere Blöcke sequentiell geschrieben, kann man nur alles wenig beeinflussen, wenn Dinge wie VSS, Shingles und 512e-Mapping usw. dazu kommen.

WBADMIN und Co. schreiben auch größere Blöcke, das ändert aber nichts daran, dass VSS, Shingles und 512e im Zweifel trotzdem parallel dazu kommen und alles schwer kontrollierbar machen. Ohne Shingles und 512e sind die gleichen Backupverfahren für den gleichen Datenbestand am gleichen Host auch schlicht schnell genug. Wenn dann also Leute schreiben,. dass ihre Shingle-Platten ebenfalls "schnell genug" sind, muss ja irgendwas bei meiner anders sein und da liegt unnötiges 512e nun mal sehr nahe.

Wenn deine Backup-Software ohne Snapshots arbeitet und Differenzen innerhalb von Dateien nicht vernünftig erkennen und weg speichern kann, ist sie übrigens Schrott.

Ich liebe es wenn Leute voreilig meinen, mir die Welt erklären zu können. An der Stelle können wir auch aufhören, der Thread ist versandet und offensichtlich hat keiner Interesse oder die nötigen USB-Platten, meine sehr konkrete Frage zu beantworten. Für weitere Grundsatzdiskussionen fehlt mir die Zeit.

 

Wenn ich den Katalog der (meist nicht lieferbaren) 16 und 18 er bei alternate durchgehe sind die meisten mit der Angabe cmr. Bei den anderen ist keine Angabe. Und bei keiner stand smr dabei.

Ich kann auch nicht nachvollziehen, warum smr für sehr große Festplatten in Frage käme, wenn die Performance in den Keller geht, sobald zuviel geschrieben wird. Gerade bei so großen Platten erwartet ich doch, dass die mal eben auch große Datenmengen in einem Rutsch aufnehmen können müssen.

Na dann ist's ja gut.

Meine Laienmeinung ist eben, das was du beschreibst sollte nicht den Einfluss haben, den du annimmst. Wenn es so wäre, wären diese Geräte nicht für den Alltag tauglich und keiner würde sowas kaufen oder verkaufen. Siehe die offensichtliche CRM Vorherrschaft bei sehr großen Datenträgern. Die gleiche Logik läßt sich übrigens für externe 2,5er anwenden, welche für Backupzwecke vermarktet wurden.

Die Schlussfolgerung ist, dass entweder etwas ganz arg schief läuft oder dein sogenannter Backupprozess genau den Worst-Case beim Schreiben darstellt.

Dinge die unerwartet kaputt sein könnten, wären zum Beispiel ein falsches Alignment deiner Platte. Dürfte eigentlich nicht sein, aber da du dich so gut auskennst, hast du das vielleicht von Hand gemacht und dich vertippt.

Du machst eher eine Synchronisation als ein Backup, wenn ich dich richtig verstehe. Aber wie dem auch sei, in welcher Größenordnung erwartest du denn einen Performanceeinbruch, wenn ein Alignment nicht stimmt, bzw. die Sektorgröße nur emuliert wird? Faktor 3? Weil dein Einbruch ist geschätzt Faktor 1000. Von geschätzten 50 Mbyte auf 100te Kbit.

Das spricht für mich dafür, dass deine Platte praktisch anhält, vermutlich weil sie in dem Bereich ist, wo Shingles sich erstmal neu sortieren müssen.

Es macht mich übrigens stutzig, dass du sagst, deine Sicherung dauert "normalerweise" Stunden. Ich dachte das ist so effizient und da wird nur ganz ganz wenig geschrieben? Ich behaupte mal dreist, wenn du Stundenlang auf eine Shingle schreibst, kommst du automatisch in den Bereich, wo die Shingle abstinkt und es ist vollkommen egal, ob da 4kn oder 512e unter der Haube ist. Das kannst du auch mit 4kn nicht richten.

Mein ineffizienter Backupprozess läuft übrigens in wenigen Minuten ab. Aber ich hab auch keine Riesendateien rumliegen, wo es effizienter ist, Teile der Datei zu sichern. Allerdings sind diese Teile wohl sehr groß, wenn es selbst bei CMR Platten Stunden dauert.

Und um deine ursprüngliche Frage zu beantworten, fast alle Platten sollten mittlerweile nativ 4k sein. Du willst aber eine Platte, die nicht mit 512e formattiert ist. Eine WD oder Seagate solltest du konvertieren können, die haben ein Tool dafür. Das WD Tool ist übrigens nur für USB und beim Seagate steht in der Einleitung der Docs, das wäre für Sata usb und sas. Aber da du dich ja auskennst, hast du das bestimmt gewußt und vermutlich keine WD/Seagate.

 

Oops. Ich les grad, du hast ja sogar eine WD. Dann konvertier das Ding doch um und fertig. Dann weißt du mehr und kannst berichten, wieviel das in der Praxis ausgemacht hat.

Man liest zwar immer von angeblichen Performanceeinbußen bei SMR und auch dass das nicht gut ist, wenn der CMR Bereich voll ist, aber Zahlen findet man eher nicht. Auch nicht, wie groß der Bereich sein soll.