warum ist der 4K read/write benchmark so wichtig?
- Ersteller Spinoza
- Erstellt am
hallo,
kann mir jemand etwas genauer erklären warum der 4K random read/write benchmark so wichtig ist?
hängt das mit der blockgröße des NTFS dateisystems zusammen?
die ist ja standard auf 4K gestellt.
gibt es zu dem thema vielleicht einen link?
hab schon bei google gesucht, eine erklärung warum dieser benchmark in der praxis so wichtig ist habe ich aber nicht gefunden.
kann mir jemand etwas genauer erklären warum der 4K random read/write benchmark so wichtig ist?
hängt das mit der blockgröße des NTFS dateisystems zusammen?
die ist ja standard auf 4K gestellt.
gibt es zu dem thema vielleicht einen link?
hab schon bei google gesucht, eine erklärung warum dieser benchmark in der praxis so wichtig ist habe ich aber nicht gefunden.
yourgreatestfear
Grand Admiral Special
Lass dir einfach mal mit einer Dateisuche alle Dateien deiner Systempartition auflisten, erweitere die Ansicht auf detailliert und sortier nach Größe.
Dann wirst du ohne Probleme feststellen können, dass einfach die Anzahl der <=4K-Dateien riesig ist im Verhältnis zum Rest. Die Blockgröße von 4K ist eher eine logische Folgeentscheidung, auch der Umstand das solche Dateien unter NTFS auch direkt in der MFT abgelegt werden und nicht wie die großen irgendwo auf der Platte.
Dann wirst du ohne Probleme feststellen können, dass einfach die Anzahl der <=4K-Dateien riesig ist im Verhältnis zum Rest. Die Blockgröße von 4K ist eher eine logische Folgeentscheidung, auch der Umstand das solche Dateien unter NTFS auch direkt in der MFT abgelegt werden und nicht wie die großen irgendwo auf der Platte.
aha.... thx.
kennst du vielleicht ein tool das mir die verteilung der filegröße als tortendiagramm anzeigt?
mit geht es nicht so sehr um festplatten als um SSD und warum immer mit 4K random write/read getestet wird.
kennst du vielleicht ein tool das mir die verteilung der filegröße als tortendiagramm anzeigt?
mit geht es nicht so sehr um festplatten als um SSD und warum immer mit 4K random write/read getestet wird.
Zuletzt bearbeitet:
yourgreatestfear
Grand Admiral Special
Nee, mit Torte kenn ich da nix.
Ob Festplatte oder SSD ist da wurscht, bei beiden Laufwerkstypen ist das Problem die kleine Blockgröße und der Aufwand diesen Block zu registrieren in der MFT. Bildlich einfach mir einem Großlager zu vergleichen. Man schickt zwei Gabelstapler los, einer mit einem einzelnen großen Paket, der andere mit 100 kleinen. Auch wenn der mit dem großen nicht ganz so schnell durch die Gänge rasen kann, weil zu schwer beladen. So fährt er nur einen Weg und schreibt nur einmal die Regalnummer auf. Der mit den kleinen darf ZickZack zwischen den Regalen fahren und muss sich jedesmal notieren wo nun was abgelegt wurde. Das kostet halt ne Menge Zeit, selbst wenn dank MFT alle kleinen Pakete nur in Gang 1 und 2 abgelegt werden, anstatt im gesamten Lager.
Es spielt also weniger eine Rolle wie schnell der Gabelstapler/die SSD ist, sondern eher wie intelligent beim Paketeverteilen vorgegangen wird.
Ob Festplatte oder SSD ist da wurscht, bei beiden Laufwerkstypen ist das Problem die kleine Blockgröße und der Aufwand diesen Block zu registrieren in der MFT. Bildlich einfach mir einem Großlager zu vergleichen. Man schickt zwei Gabelstapler los, einer mit einem einzelnen großen Paket, der andere mit 100 kleinen. Auch wenn der mit dem großen nicht ganz so schnell durch die Gänge rasen kann, weil zu schwer beladen. So fährt er nur einen Weg und schreibt nur einmal die Regalnummer auf. Der mit den kleinen darf ZickZack zwischen den Regalen fahren und muss sich jedesmal notieren wo nun was abgelegt wurde. Das kostet halt ne Menge Zeit, selbst wenn dank MFT alle kleinen Pakete nur in Gang 1 und 2 abgelegt werden, anstatt im gesamten Lager.
Es spielt also weniger eine Rolle wie schnell der Gabelstapler/die SSD ist, sondern eher wie intelligent beim Paketeverteilen vorgegangen wird.
PuckPoltergeist
Grand Admiral Special
Da spielt schon die Blockgröße des Dateisystems die Hauptrolle. Die ist standardmäßig auf 4k gesetzt, also die kleinste Einheit, die gelesen oder geschrieben werden kann. Und das ist gerade für SSDs relevant, da diese nicht mehr mit 512Byte Sektoren arbeiten, wie Festplatten, sondern mit wesentlich größeren Sektoren, 64kB wenn ich nicht irre. Das heißt, mit den Standard-Dateisystemen, die darauf arbeiten, fällt für eine SSD sehr viel mehr Arbeit an, als für eine Festplatte.
ssd arbeiten laut anandtech mit sogenannten pages von 4kb. diese entsprechen den sektoren von festplatten, sind dafür aber größer. die 4kb-werte sind vermutlich deshalb so wichtig, weil ssds immer pageweise schreiben und betriebsysteme sehr viele kleine datenhäppchen schreiben. das löschen von daten in ssds erfolgt allerdings immer in ganzen erase blocks von 128 pages, also 512 kb.
PuckPoltergeist
Grand Admiral Special
Link? Weil, das wäre mir neu.
Das ist definitiv falsch. Festplatten arbeiten nach wie vor noch mit Sektorgrößen von 512Byte. Sonst würden sämtliche Betriebssystem heute nicht mehr laufen.
Betriebssystem schreiben in der Größe, wie die Blockgröße des Dateisystems ist. Und das ist bei der Mehrzahl der verwendeten Dateisystem heute 4k.
ad1: http://www.anandtech.com/storage/showdoc.aspx?i=3631
ad2: klar nutzen festplatten noch 512 byte große sektoren, doch für die zukunft sind 4 kbyte geplant (einzige quelle, dazu, die ich z.z. zur hand hab ist der 2. absatz von: http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/). die ssd versteht zwar die addressierung auf basis von 512 byte sektoren, doch hantiert die ssd intern nicht mit 512 byte sektoren, sondern 4 kb "pages". mein satz im vorherigen post bezog sich darauf, dass ssd intern in pages "denken", so wie hdd intern in sektoren "denken"
ad3: bist du die sicher, dass immer, also auch beim ändern von bereits vorhandenen daten ganze fs-blöcke geschrieben werden? ich kanns jetzt nicht widerlegen, aber es erscheint mir nicht sinnvoll, so vorzugehen. gerade bei änderungen von metadaten. auch werden bei aktuellen dateisystemen (ext4, xfs, nilfs und afaik auch btrfs) immer häufiger extents variabler größe verwendet anstelle von fs-blöcken fester größe.
ad2: klar nutzen festplatten noch 512 byte große sektoren, doch für die zukunft sind 4 kbyte geplant (einzige quelle, dazu, die ich z.z. zur hand hab ist der 2. absatz von: http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/). die ssd versteht zwar die addressierung auf basis von 512 byte sektoren, doch hantiert die ssd intern nicht mit 512 byte sektoren, sondern 4 kb "pages". mein satz im vorherigen post bezog sich darauf, dass ssd intern in pages "denken", so wie hdd intern in sektoren "denken"
ad3: bist du die sicher, dass immer, also auch beim ändern von bereits vorhandenen daten ganze fs-blöcke geschrieben werden? ich kanns jetzt nicht widerlegen, aber es erscheint mir nicht sinnvoll, so vorzugehen. gerade bei änderungen von metadaten. auch werden bei aktuellen dateisystemen (ext4, xfs, nilfs und afaik auch btrfs) immer häufiger extents variabler größe verwendet anstelle von fs-blöcken fester größe.
PuckPoltergeist
Grand Admiral Special
Ich gebs zu, ich habs nur überflogen und auch nur teilweise, aber:
Der NAND-Flash ist aus 4kB Zellen aufgebaut, die SSDs arbeiten auf wesentlich größeren Blöcken, so mich mein Leseverständnis jetzt nicht im Stich lässt.
Die Idee gibts schon länger. Ob es dazu kommt, wird sich zeigen müssen. Wie gesagt, die Betriebssysteme müssen dem angepasst werden.
Der Controller abstrahiert das, das ist klar. Aber ich gehe immer noch davon aus, dass das mehr als 4kB sind.
Ja, da bin ich sicher. Die Blockgröße ist die elementare Einheit des Dateisystems. Und auch Extents ändern daran nichts. Die machen nur die Adressierung einfacher. Die kleinste Einheit bleibt auch da die Blockgröße (4KB im Normalfall).
laut anandtech sind die pages 4 kb groß, die logischen pages können auch größer sein. das ist das, was du oben zitiert hast. auf derselben seite ganz unten steht allerdings:
demnach verwenden die indilinx basierten ssd logische pages von der größe einer "echten" page, also 4kb. die leistung im normalen betrieb als systemplatte wäre sonst deutlich bescheidener. größere logische pages finden eher verwendung in kameras, da dort daten nicht in kleinen häppchen, sondern imemr gleich mb-weise anfallen.
Ähnliche Themen
