Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Wartung SSD Platte?
1,871 views
Skip to first unread message
Turtle
Aug 30, 2013, 5:14:14 AM8/30/13
to
Hallo Zusammen,
nach einem Windows Absturz mit einer HDD Festplatte macht man eine chdsk
oder Fehlerüberprüfung und defragmentieren.
Bei einer SSD Platte ist das NICHT der Fall.
Was macht man denn nach einem Windows Absturz mit einer SSD Festplatte?
bis bald,
nach einem Windows Absturz mit einer HDD Festplatte macht man eine chdsk
oder Fehlerüberprüfung und defragmentieren.
Bei einer SSD Platte ist das NICHT der Fall.
Was macht man denn nach einem Windows Absturz mit einer SSD Festplatte?
bis bald,
Hermann
Aug 30, 2013, 6:23:49 AM8/30/13
to
Betriebssystem?
Gruß
Hermann
Marcel Müller
Aug 30, 2013, 6:42:09 AM8/30/13
to
Hallo,
On 30.08.2013 11:14, Turtle wrote:
> Hallo Zusammen,
>
> nach einem Windows Absturz mit einer HDD Festplatte macht man eine chdsk
ja, automatisch
> oder Fehlerüberprüfung
was für eine Fehlerprüfung? CHKDSK ist die Fehlerprüfung.
> und defragmentieren.
nein, da gibt keinen Zusammenhang mit einem Absturz.
> Bei einer SSD Platte ist das NICHT der Fall.
Bei einer SSD ist das exakt dasselbe.
> Was macht man denn nach einem Windows Absturz mit einer SSD Festplatte?
CHKDSK wird automatisch ausgeführt. Allerdings geht das auf einer SSD
möglicherweise so schnell, dass man es kaum merkt.
Defragmentierung sollte man auf einer SSD grundsätzlich lassen.
Marcel
On 30.08.2013 11:14, Turtle wrote:
> Hallo Zusammen,
>
> nach einem Windows Absturz mit einer HDD Festplatte macht man eine chdsk
> oder Fehlerüberprüfung
was für eine Fehlerprüfung? CHKDSK ist die Fehlerprüfung.
> und defragmentieren.
nein, da gibt keinen Zusammenhang mit einem Absturz.
> Bei einer SSD Platte ist das NICHT der Fall.
> Was macht man denn nach einem Windows Absturz mit einer SSD Festplatte?
möglicherweise so schnell, dass man es kaum merkt.
Defragmentierung sollte man auf einer SSD grundsätzlich lassen.
Marcel
Helmut Hullen
Aug 30, 2013, 9:48:00 AM8/30/13
to
Hallo, Turtle,
Du meintest am 30.08.13:
> nach einem Windows Absturz mit einer HDD Festplatte macht man eine
> chdsk oder Fehler�berpr�fung und defragmentieren.
> Bei einer SSD Platte ist das NICHT der Fall.
Bei einer SSD ist Defragmentieren mindestens unn�tig, aber
wahrscheinlich komplett unsinnig.
Viele Gruesse!
Helmut
Du meintest am 30.08.13:
> nach einem Windows Absturz mit einer HDD Festplatte macht man eine
> Bei einer SSD Platte ist das NICHT der Fall.
wahrscheinlich komplett unsinnig.
Viele Gruesse!
Helmut
Tom Schneider
Aug 30, 2013, 4:19:35 PM8/30/13
to
Turtle schrieb:
> Hallo Zusammen,
> Bei einer SSD Platte ist das NICHT der Fall.
> Was macht man denn nach einem Windows Absturz mit einer SSD Festplatte?
Windows merkt nicht jeden Fehler. Ein
chkdsk SSD: /F /X
kann also nie schaden.
Defragmentieren ist eher schädlich, da bei einer SSD das Management der
benutzten Blöcke komplett eigene Wege geht und die grundlegende Idee der
Defragmentierung aus der Zeit früher HDDs kommt.
Aus DOS-Zeiten erinnere ich mich noch an den Interleave-Faktor, wenn die
HDD schneller rotierte als sie ausgelesen werden konnte. Dann konnte mit
dem Interleave eingestellt, dass nur jeder zweite oder dritte Sektor
gelesen wird, was dazu führte, dass die Scheibe entsprechend mehrfach
rotieren musste, bis alle Daten auf der Spur eingelesen waren.
Kopfbewegungszeiten spielen bei der SSD auch keine Rolle mehr, daher
würde Defragmentieren (fast?) nichts mehr bringen. Außer natürlich
Stromverbrauch und einem blockiertem Rechner.
> Hallo Zusammen,
> Bei einer SSD Platte ist das NICHT der Fall.
> Was macht man denn nach einem Windows Absturz mit einer SSD Festplatte?
chkdsk SSD: /F /X
kann also nie schaden.
Defragmentieren ist eher schädlich, da bei einer SSD das Management der
benutzten Blöcke komplett eigene Wege geht und die grundlegende Idee der
Defragmentierung aus der Zeit früher HDDs kommt.
Aus DOS-Zeiten erinnere ich mich noch an den Interleave-Faktor, wenn die
HDD schneller rotierte als sie ausgelesen werden konnte. Dann konnte mit
dem Interleave eingestellt, dass nur jeder zweite oder dritte Sektor
gelesen wird, was dazu führte, dass die Scheibe entsprechend mehrfach
rotieren musste, bis alle Daten auf der Spur eingelesen waren.
Kopfbewegungszeiten spielen bei der SSD auch keine Rolle mehr, daher
würde Defragmentieren (fast?) nichts mehr bringen. Außer natürlich
Stromverbrauch und einem blockiertem Rechner.
Marcel Müller
Aug 31, 2013, 2:06:57 AM8/31/13
to
Hallo,
On 30.08.13 22.19, Tom Schneider wrote:
> Defragmentieren ist eher schädlich, da bei einer SSD das Management der
> benutzten Blöcke komplett eigene Wege geht und die grundlegende Idee der
> Defragmentierung aus der Zeit früher HDDs kommt.
so schaut's. Dem liegt die Annahme zugrunde, dass der Zugriff auf
benachbarte logische Blocknummern deutlich schneller ist, als auf
beliebige. Die Annahme ist bei Random-Access-Devices wie Speicherchips
falsch.
> Aus DOS-Zeiten erinnere ich mich noch an den Interleave-Faktor, wenn die
> HDD schneller rotierte als sie ausgelesen werden konnte. Dann konnte mit
> dem Interleave eingestellt, dass nur jeder zweite oder dritte Sektor
> gelesen wird, was dazu führte, dass die Scheibe entsprechend mehrfach
> rotieren musste, bis alle Daten auf der Spur eingelesen waren.
Ich weiß nicht. Als ich mit dem Thema Interleave Ende der 80er in
Berührung kam, war es eigentlich schon ein Anachronismus. Jedenfalls
wurde so jeder PC deutlich schneller, wenn es gelang die Festplatte mit
Interleave 1 neu Low-Level zu formatieren. Standard war oft 3. Aber
selbst ein 286er hat es i.a. geschafft, die paar kb/s, die damalige
Platten geliefert haben, wegzuschaffen.
> Kopfbewegungszeiten spielen bei der SSD auch keine Rolle mehr, daher
> würde Defragmentieren (fast?) nichts mehr bringen.
Im Gegenteil. Die SSD wird dabei i.a. langsamer, weil sie intern
fragmentiert.
Der SSD ist es sowieso egal, auf welche logischen Blocknummern die Daten
geschrieben werden. Sie schreibt hin wo sie will und merkt sich nur wo.
Man muss sich eine SSD mit Wear-Leveling eher vorstellen wie eine
Datenbank, wo unter einem eindeutigen Primärschlüssel, der Logischen
Block Nummer, feste Datenpakete, die Sektoren, abgelegt werden. Wenn ich
einer SSD den Befehl gebe, die Blöcke 7, 18 und 278 zu schreiben (*),
wird sie die Daten i.a. hintereinander in eine freie Page schreiben und
die alten Blöcke, die zu diesen Blocknummern gehören trimmen (= als zum
löschen freigegeben markieren). Und wenn (fast) alle Blöcke in einem
Erase-Block (z.B. 128 kB) als frei markiert sind, macht die SSD den
Erase-Block platt, um neue Schreibbefehle ausführen zu können. Wenn alle
Erase Blöcke nur halb leer sind, dann muss die SSD erst intern
defragmentieren, denn Erase-Blocks können immer nur komplett gelöscht
werden. Das gibt dann leichte Verzögerungen beim Schreiben.
(*) Aufpassen, SSDs verwenden wie Advanced Format Festplatten 4k Blöcke
und tun nur aus kompatibilitätsgründen so, als hätten sie 512 Bytes
Sektoren. Ohne dieses Kompatibilitätslayer würden die Alignment Probleme
gar nicht existieren.
> Außer natürlich
> Stromverbrauch und einem blockiertem Rechner.
Eine SSD wird selbst bei der Defragmentierung i.a. nicht blockieren. Das
ist für sie wie Files kopieren. Das geht auch nebenher.
Marcel
On 30.08.13 22.19, Tom Schneider wrote:
> Defragmentieren ist eher schädlich, da bei einer SSD das Management der
> benutzten Blöcke komplett eigene Wege geht und die grundlegende Idee der
> Defragmentierung aus der Zeit früher HDDs kommt.
benachbarte logische Blocknummern deutlich schneller ist, als auf
beliebige. Die Annahme ist bei Random-Access-Devices wie Speicherchips
falsch.
> Aus DOS-Zeiten erinnere ich mich noch an den Interleave-Faktor, wenn die
> HDD schneller rotierte als sie ausgelesen werden konnte. Dann konnte mit
> dem Interleave eingestellt, dass nur jeder zweite oder dritte Sektor
> gelesen wird, was dazu führte, dass die Scheibe entsprechend mehrfach
> rotieren musste, bis alle Daten auf der Spur eingelesen waren.
Berührung kam, war es eigentlich schon ein Anachronismus. Jedenfalls
wurde so jeder PC deutlich schneller, wenn es gelang die Festplatte mit
Interleave 1 neu Low-Level zu formatieren. Standard war oft 3. Aber
selbst ein 286er hat es i.a. geschafft, die paar kb/s, die damalige
Platten geliefert haben, wegzuschaffen.
> Kopfbewegungszeiten spielen bei der SSD auch keine Rolle mehr, daher
> würde Defragmentieren (fast?) nichts mehr bringen.
fragmentiert.
Der SSD ist es sowieso egal, auf welche logischen Blocknummern die Daten
geschrieben werden. Sie schreibt hin wo sie will und merkt sich nur wo.
Man muss sich eine SSD mit Wear-Leveling eher vorstellen wie eine
Datenbank, wo unter einem eindeutigen Primärschlüssel, der Logischen
Block Nummer, feste Datenpakete, die Sektoren, abgelegt werden. Wenn ich
einer SSD den Befehl gebe, die Blöcke 7, 18 und 278 zu schreiben (*),
wird sie die Daten i.a. hintereinander in eine freie Page schreiben und
die alten Blöcke, die zu diesen Blocknummern gehören trimmen (= als zum
löschen freigegeben markieren). Und wenn (fast) alle Blöcke in einem
Erase-Block (z.B. 128 kB) als frei markiert sind, macht die SSD den
Erase-Block platt, um neue Schreibbefehle ausführen zu können. Wenn alle
Erase Blöcke nur halb leer sind, dann muss die SSD erst intern
defragmentieren, denn Erase-Blocks können immer nur komplett gelöscht
werden. Das gibt dann leichte Verzögerungen beim Schreiben.
(*) Aufpassen, SSDs verwenden wie Advanced Format Festplatten 4k Blöcke
und tun nur aus kompatibilitätsgründen so, als hätten sie 512 Bytes
Sektoren. Ohne dieses Kompatibilitätslayer würden die Alignment Probleme
gar nicht existieren.
> Außer natürlich
> Stromverbrauch und einem blockiertem Rechner.
ist für sie wie Files kopieren. Das geht auch nebenher.
Marcel
Hergen Lehmann
Aug 31, 2013, 4:15:41 AM8/31/13
to
On 31.08.2013 08:06, Marcel Mï¿œller wrote:
>> Defragmentieren ist eher schï¿œdlich, da bei einer SSD das Management der
>> benutzten Blï¿œcke komplett eigene Wege geht und die grundlegende Idee der
>> Defragmentierung aus der Zeit frï¿œher HDDs kommt.
einem Rutsch gelesen werden, wï¿œhrend bei einer fragmentierten Datei
mindestens pro Fragment eine neue Transaktion begonnen und mit Pech
zwischendurch sogar noch Verwaltungsinformationen gelesen werden mï¿œssen,
um die Adresse des nï¿œchsten Fragments zu bestimmen.
Es kann daher durchaus sinnvoll sein, einzelne, sehr stark fragmentierte
Dateien (z.B. ï¿œber einen langen Zeitraum gewachsene Datenbanken) zu
defragmentieren.
Die althergebrachten Defragmentier-Programme nach dem Motto "viel hilft
viel" sind aber in der Tat bei einer SSD grober Unfug.
Hergen
>> Defragmentieren ist eher schï¿œdlich, da bei einer SSD das Management der
>> benutzten Blï¿œcke komplett eigene Wege geht und die grundlegende Idee der
>> Defragmentierung aus der Zeit frï¿œher HDDs kommt.
>
> so schaut's. Dem liegt die Annahme zugrunde, dass der Zugriff auf
> benachbarte logische Blocknummern deutlich schneller ist, als auf
> beliebige. Die Annahme ist bei Random-Access-Devices wie Speicherchips
> falsch.
Jein. Auch bei SSDs gilt: Direkt aufeinander folgende Blï¿œcke kï¿œnnen in
> so schaut's. Dem liegt die Annahme zugrunde, dass der Zugriff auf
> benachbarte logische Blocknummern deutlich schneller ist, als auf
> beliebige. Die Annahme ist bei Random-Access-Devices wie Speicherchips
> falsch.
einem Rutsch gelesen werden, wï¿œhrend bei einer fragmentierten Datei
mindestens pro Fragment eine neue Transaktion begonnen und mit Pech
zwischendurch sogar noch Verwaltungsinformationen gelesen werden mï¿œssen,
um die Adresse des nï¿œchsten Fragments zu bestimmen.
Es kann daher durchaus sinnvoll sein, einzelne, sehr stark fragmentierte
Dateien (z.B. ï¿œber einen langen Zeitraum gewachsene Datenbanken) zu
defragmentieren.
Die althergebrachten Defragmentier-Programme nach dem Motto "viel hilft
viel" sind aber in der Tat bei einer SSD grober Unfug.
Hergen
Helmut Hullen
Aug 31, 2013, 4:52:00 AM8/31/13
to
Hallo, Hergen,
Du meintest am 31.08.13:
>>> Defragmentieren ist eher sch�dlich, da bei einer SSD das Management
>>> der benutzten Bl�cke komplett eigene Wege geht und die grundlegende
>>> Idee der Defragmentierung aus der Zeit fr�her HDDs kommt.
[...]
> Jein. Auch bei SSDs gilt: Direkt aufeinander folgende Bl�cke k�nnen
> in einem Rutsch gelesen werden, w�hrend bei einer fragmentierten
Wieviele Nanosekunden macht das aus?
Kopfbewegungen bei einer Festplatte liegen im Millisekundenbereich ...
Viele Gruesse!
Helmut
Du meintest am 31.08.13:
>>> Defragmentieren ist eher sch�dlich, da bei einer SSD das Management
>>> der benutzten Bl�cke komplett eigene Wege geht und die grundlegende
>>> Idee der Defragmentierung aus der Zeit fr�her HDDs kommt.
[...]
> Jein. Auch bei SSDs gilt: Direkt aufeinander folgende Bl�cke k�nnen
> in einem Rutsch gelesen werden, w�hrend bei einer fragmentierten
> Datei mindestens pro Fragment eine neue Transaktion begonnen und mit
> Pech zwischendurch sogar noch Verwaltungsinformationen gelesen werden
> m�ssen, um die Adresse des n�chsten Fragments zu bestimmen.
> Pech zwischendurch sogar noch Verwaltungsinformationen gelesen werden
Wieviele Nanosekunden macht das aus?
Kopfbewegungen bei einer Festplatte liegen im Millisekundenbereich ...
Viele Gruesse!
Helmut
Marcel Müller
Aug 31, 2013, 10:49:28 AM8/31/13
to
On 31.08.13 10.15, Hergen Lehmann wrote:
>> so schaut's. Dem liegt die Annahme zugrunde, dass der Zugriff auf
>> benachbarte logische Blocknummern deutlich schneller ist, als auf
>> beliebige. Die Annahme ist bei Random-Access-Devices wie Speicherchips
>> falsch.
>
> Jein. Auch bei SSDs gilt: Direkt aufeinander folgende Blöcke können in
>> so schaut's. Dem liegt die Annahme zugrunde, dass der Zugriff auf
>> benachbarte logische Blocknummern deutlich schneller ist, als auf
>> beliebige. Die Annahme ist bei Random-Access-Devices wie Speicherchips
>> falsch.
>
> einem Rutsch gelesen werden, während bei einer fragmentierten Datei
> mindestens pro Fragment eine neue Transaktion begonnen und mit Pech
> zwischendurch sogar noch Verwaltungsinformationen gelesen werden müssen,
> um die Adresse des nächsten Fragments zu bestimmen.
Dumm nur, dass aufeinander folgende Blocknummern bei SSDs i.a. nicht in
benachbarten Speicherzellen stehen. Man wird diese Optimierung also dem
SSD Controller überlassen müssen.
> Es kann daher durchaus sinnvoll sein, einzelne, sehr stark fragmentierte
> defragmentieren.
Nein.
Wenn man bei einer SSD unter interner Fragmentierung leidet, weil schon
viel Kleinkram auf selbige geschrieben wurde, ohne dass ein
signifikanter Teil des Platzes bekanntermaßen frei (getrimmt) war, dann
hilft nur einmal komplett platt machen (trimmen) und den Inhalt komplett
neu aufspielen.
Ein Defrag erreicht dieses Ziel nicht, denn dazu muss der für die SSD
erkennbar freie Bereich vor den nächsten Schreibzugriffen erheblich
vergrößert werden. Defrag verkleinert diesen aber sogar um mindestens
eine Dateigröße.
Marcel
Thomas Orgelmacher
Aug 31, 2013, 4:51:01 PM8/31/13
to
Am 31.08.2013 10:15, schrieb Hergen Lehmann:
>
> Jein. Auch bei SSDs gilt: Direkt aufeinander folgende Blöcke können in
> einem Rutsch gelesen werden, während bei einer fragmentierten Datei
bei SSDs keinen zwingenden Zusammenhang zwischen logischem und
physikalischem Sektor/Block/wasauch immer.
Auch wenn die logischen Sektoren in Folge liegen sollten, heißt das
nicht, dass die Physik genauso orientiert ist. Und da man idR, keine
Infos über Controller, Firmware und deren Zusammenspiel bekommt, sind
alle Annahmen in diesem Bereich ziemlich akademisch.
Gruß, Thomas
--
I have seen things you lusers would not believe. I've seen Sun
monitors on fire off the side of the multimedia lab. I've seen
NTU lights glitter in the dark near the Mail Gate. All these
things will be lost in time, like the root partition last week.
>
> Jein. Auch bei SSDs gilt: Direkt aufeinander folgende Blöcke können in
> einem Rutsch gelesen werden, während bei einer fragmentierten Datei
> mindestens pro Fragment eine neue Transaktion begonnen und mit Pech
> zwischendurch sogar noch Verwaltungsinformationen gelesen werden müssen,
> um die Adresse des nächsten Fragments zu bestimmen.
Wenn ich das jetzt nicht grundsätzlich flasch verstanden habe, gibt es
> um die Adresse des nächsten Fragments zu bestimmen.
bei SSDs keinen zwingenden Zusammenhang zwischen logischem und
physikalischem Sektor/Block/wasauch immer.
Auch wenn die logischen Sektoren in Folge liegen sollten, heißt das
nicht, dass die Physik genauso orientiert ist. Und da man idR, keine
Infos über Controller, Firmware und deren Zusammenspiel bekommt, sind
alle Annahmen in diesem Bereich ziemlich akademisch.
Gruß, Thomas
--
I have seen things you lusers would not believe. I've seen Sun
monitors on fire off the side of the multimedia lab. I've seen
NTU lights glitter in the dark near the Mail Gate. All these
things will be lost in time, like the root partition last week.
Hergen Lehmann
Sep 1, 2013, 6:30:21 AM9/1/13
to
On 31.08.2013 22:51, Thomas Orgelmacher wrote:
> Wenn ich das jetzt nicht grundsï¿œtzlich flasch verstanden habe, gibt es
darum ging es an dieser Stelle auch gar nicht.
> Und da man idR, keine
> Infos ï¿œber Controller, Firmware und deren Zusammenspiel bekommt, sind
akademischen Exkurs, um zu erkennen, daￜ (starke) Fragmentierung auf
dieser Ebene einen erheblichen IO-Overhead erzeugt. Dieser mag bei SSD
nicht ganz so weh tun wie bei HDD, ist deshalb aber noch lange nicht
irrelevant.
Und auch der Datendurchsatz der SATA-Schnittstelle sinkt bei Random-Read
spï¿œrbar gegenï¿œber Sequential-Read.
Hergen
> Wenn ich das jetzt nicht grundsï¿œtzlich flasch verstanden habe, gibt es
> bei SSDs keinen zwingenden Zusammenhang zwischen logischem und
> physikalischem Sektor/Block/wasauch immer.
> Auch wenn die logischen Sektoren in Folge liegen sollten, heiï¿œt das
> physikalischem Sektor/Block/wasauch immer.
> nicht, dass die Physik genauso orientiert ist.
Das ist auch bei HDDs schon lange nicht mehr zwingend der Fall. Aber
darum ging es an dieser Stelle auch gar nicht.
> Und da man idR, keine
> alle Annahmen in diesem Bereich ziemlich akademisch.
Die meisten Dateisysteme sind gut dokumentiert, und es erfordert keinen
akademischen Exkurs, um zu erkennen, daￜ (starke) Fragmentierung auf
dieser Ebene einen erheblichen IO-Overhead erzeugt. Dieser mag bei SSD
nicht ganz so weh tun wie bei HDD, ist deshalb aber noch lange nicht
irrelevant.
Und auch der Datendurchsatz der SATA-Schnittstelle sinkt bei Random-Read
spï¿œrbar gegenï¿œber Sequential-Read.
Hergen
Thomas Orgelmacher
Sep 1, 2013, 10:56:21 AM9/1/13
to
Am 01.09.2013 12:30, schrieb Hergen Lehmann:
>
> Die meisten Dateisysteme sind gut dokumentiert, und es erfordert keinen
> akademischen Exkurs, um zu erkennen, daß (starke) Fragmentierung auf
>
> Die meisten Dateisysteme sind gut dokumentiert, und es erfordert keinen
> dieser Ebene einen erheblichen IO-Overhead erzeugt. Dieser mag bei SSD
> nicht ganz so weh tun wie bei HDD, ist deshalb aber noch lange nicht
> irrelevant.
Hmm, ich finde nichts wirklich tragfähiges zu dem Thema. Du meinst also,
> nicht ganz so weh tun wie bei HDD, ist deshalb aber noch lange nicht
> irrelevant.
das Verfolgen der ganzen Extends (z.B.) einer fragmentierten Datei?
Um welche Größenordnung geht es dabei?
Das hieße auf der anderen Seite, dass die Fragmentierung bei einem FAT-
basierten Dateisystem egal wäre, weil jeder Block nach dem gleichem
Schema lokalisiert wird?
Hergen Lehmann
Sep 1, 2013, 12:13:29 PM9/1/13
to
On 01.09.2013 16:56, Thomas Orgelmacher wrote:
> Hmm, ich finde nichts wirklich tragfï¿œhiges zu dem Thema. Du meinst also,
> Um welche Grￜￜenordnung geht es dabei?
Hï¿œngt sehr stark vom Dateisystem und vom Grad der Fragmentierung ab.
Unter normalen Umstï¿œnden wï¿œrde ich durch den Verwaltungsoverhead bei
unnï¿œtig kleinen Extends nur einen Durchsatzverlust im Bereich von
Promille bis wenigen Prozent erwarten. Unter ungï¿œnstigen Umstï¿œnden (ï¿œber
lange Zeitrï¿œume in kleinen Hï¿œppchen gewachsene und dadurch stark
fragmentierte Datei) kann das aber je nach Dateisystem auch deutlich
mehr werden.
Dies wohlgemerkt fï¿œr SSD; bei HDD treiben die Seek-Zeiten den Durchsatz
bei fragmentierten Dateien dramatisch in den Keller.
> Das hieï¿œe auf der anderen Seite, dass die Fragmentierung bei einem FAT-
> basierten Dateisystem egal wï¿œre, weil jeder Block nach dem gleichem
> Schema lokalisiert wird?
Nein, gerade FAT ist der schlimmst mï¿œgliche Fall, da dieses antike
Dateisystem weder Extents kennt, noch Maï¿œnahmen zur vorsorglichen
Vermeidung von Fragmentierung. Im "worst case" muss bei FAT vor jedem
logischen Datenblock (im zweistelligen Kilobyte-Bereich) zunï¿œchst ein
Verwaltungsblock der selben Grￜￜe gelesen werden.
Hergen
> Hmm, ich finde nichts wirklich tragfï¿œhiges zu dem Thema. Du meinst also,
> das Verfolgen der ganzen Extends (z.B.) einer fragmentierten Datei?
Ja.
> Um welche Grￜￜenordnung geht es dabei?
Hï¿œngt sehr stark vom Dateisystem und vom Grad der Fragmentierung ab.
Unter normalen Umstï¿œnden wï¿œrde ich durch den Verwaltungsoverhead bei
unnï¿œtig kleinen Extends nur einen Durchsatzverlust im Bereich von
Promille bis wenigen Prozent erwarten. Unter ungï¿œnstigen Umstï¿œnden (ï¿œber
lange Zeitrï¿œume in kleinen Hï¿œppchen gewachsene und dadurch stark
fragmentierte Datei) kann das aber je nach Dateisystem auch deutlich
mehr werden.
Dies wohlgemerkt fï¿œr SSD; bei HDD treiben die Seek-Zeiten den Durchsatz
bei fragmentierten Dateien dramatisch in den Keller.
> Das hieï¿œe auf der anderen Seite, dass die Fragmentierung bei einem FAT-
> basierten Dateisystem egal wï¿œre, weil jeder Block nach dem gleichem
> Schema lokalisiert wird?
Nein, gerade FAT ist der schlimmst mï¿œgliche Fall, da dieses antike
Dateisystem weder Extents kennt, noch Maï¿œnahmen zur vorsorglichen
Vermeidung von Fragmentierung. Im "worst case" muss bei FAT vor jedem
logischen Datenblock (im zweistelligen Kilobyte-Bereich) zunï¿œchst ein
Verwaltungsblock der selben Grￜￜe gelesen werden.
Hergen
Martin Schoenbeck
Sep 1, 2013, 2:54:48 PM9/1/13
to
Hallo Hergen,
Hergen Lehmann schrieb:
> Das ist auch bei HDDs schon lange nicht mehr zwingend der Fall. Aber
> darum ging es an dieser Stelle auch gar nicht.
Bei HDDs ist es die Ausnahme, bei SSDs die Regel.
>> Und da man idR, keine
>> Infos �ber Controller, Firmware und deren Zusammenspiel bekommt, sind
> Und auch der Datendurchsatz der SATA-Schnittstelle sinkt bei Random-Read
> sp�rbar gegen�ber Sequential-Read.
Erz�hl: wie kommst Du auf diese absurde Idee? Mal vorausgesetzt, Du gehst
nicht von PIO-Zugriffen auf den Controller aus.
Gru� Martin
--
Bitte nicht an der E-Mail-Adresse fummeln, die pa�t so.
Hergen Lehmann schrieb:
> Das ist auch bei HDDs schon lange nicht mehr zwingend der Fall. Aber
> darum ging es an dieser Stelle auch gar nicht.
>> Und da man idR, keine
>> alle Annahmen in diesem Bereich ziemlich akademisch.
>
> Die meisten Dateisysteme sind gut dokumentiert, und es erfordert keinen
> akademischen Exkurs, um zu erkennen, da� (starke) Fragmentierung auf
>
> Die meisten Dateisysteme sind gut dokumentiert, und es erfordert keinen
> dieser Ebene einen erheblichen IO-Overhead erzeugt. Dieser mag bei SSD
> nicht ganz so weh tun wie bei HDD, ist deshalb aber noch lange nicht
> irrelevant.
Es _ist_ irrelevant. Es hat keinerlei me�bare Auswirkung.
> nicht ganz so weh tun wie bei HDD, ist deshalb aber noch lange nicht
> irrelevant.
> Und auch der Datendurchsatz der SATA-Schnittstelle sinkt bei Random-Read
Erz�hl: wie kommst Du auf diese absurde Idee? Mal vorausgesetzt, Du gehst
nicht von PIO-Zugriffen auf den Controller aus.
Gru� Martin
--
Bitte nicht an der E-Mail-Adresse fummeln, die pa�t so.
Hergen Lehmann
Sep 1, 2013, 4:25:46 PM9/1/13
to
On 01.09.2013 20:54, Martin Schoenbeck wrote:
>> Die meisten Dateisysteme sind gut dokumentiert, und es erfordert keinen
>> akademischen Exkurs, um zu erkennen, da� (starke) Fragmentierung auf
>> dieser Ebene einen erheblichen IO-Overhead erzeugt. Dieser mag bei SSD
>> nicht ganz so weh tun wie bei HDD, ist deshalb aber noch lange nicht
>> irrelevant.
>
> Es _ist_ irrelevant. Es hat keinerlei me�bare Auswirkung.
Ungef�hr so wie unten?
>> Die meisten Dateisysteme sind gut dokumentiert, und es erfordert keinen
>> akademischen Exkurs, um zu erkennen, da� (starke) Fragmentierung auf
>> dieser Ebene einen erheblichen IO-Overhead erzeugt. Dieser mag bei SSD
>> nicht ganz so weh tun wie bei HDD, ist deshalb aber noch lange nicht
>> irrelevant.
>
> Es _ist_ irrelevant. Es hat keinerlei me�bare Auswirkung.
>> Und auch der Datendurchsatz der SATA-Schnittstelle sinkt bei Random-Read
>> sp�rbar gegen�ber Sequential-Read.
>
> Erz�hl: wie kommst Du auf diese absurde Idee?
bevor sie die Klappe aufreissen:
http://www.tomshardware.com/charts/ssd-charts-2012/AS-SSD-4K-Random-Read,2784.html
http://www.tomshardware.com/charts/ssd-charts-2012/AS-SSD-Sequential-Read,2782.html
Im Schnitt mehr als Faktor 10, bei einzelnen Fabrikaten sogar noch
deutlich mehr! Das ist jetzt sogar noch drastischer, als ich in
Erinnerung hatte.
Und um dem Einwand gleich vorzubeugen: 4K ist die Default-Blockgr��e von
NTFS bei Partitionen bis 2GB. ext4 liegt �hnlich. Der Test spiegelt also
gut wieder, was im worst case passiert.
Hergen
Hergen Lehmann
Sep 1, 2013, 4:57:44 PM9/1/13
to
On 01.09.2013 22:25, Hergen Lehmann wrote:
> Und um dem Einwand gleich vorzubeugen: 4K ist die Default-Blockgr��e von
> NTFS bei Partitionen bis 2GB.
2TB nat�rlich!
> Und um dem Einwand gleich vorzubeugen: 4K ist die Default-Blockgr��e von
> NTFS bei Partitionen bis 2GB.
Hendrik van der Heijden
Sep 2, 2013, 3:02:08 AM9/2/13
to
Am 01.09.2013 22:25, schrieb Hergen Lehmann:
>>> Und auch der Datendurchsatz der SATA-Schnittstelle sinkt bei Random-Read
>>> spürbar gegenüber Sequential-Read.
>>> Und auch der Datendurchsatz der SATA-Schnittstelle sinkt bei Random-Read
>>
>> Erzähl: wie kommst Du auf diese absurde Idee?
>
> Vorsicht, Herr Doktor. Vielleicht schauen sie doch mal besser nach,
> bevor sie die Klappe aufreissen:
>
> http://www.tomshardware.com/charts/ssd-charts-2012/AS-SSD-4K-Random-Read,2784.html
> http://www.tomshardware.com/charts/ssd-charts-2012/AS-SSD-Sequential-Read,2782.html
>
> Im Schnitt mehr als Faktor 10, bei einzelnen Fabrikaten sogar noch
> deutlich mehr! Das ist jetzt sogar noch drastischer, als ich in
> Erinnerung hatte.
Ist hier aber nicht wirklich zutreffend.
> Vorsicht, Herr Doktor. Vielleicht schauen sie doch mal besser nach,
> bevor sie die Klappe aufreissen:
>
> http://www.tomshardware.com/charts/ssd-charts-2012/AS-SSD-4K-Random-Read,2784.html
> http://www.tomshardware.com/charts/ssd-charts-2012/AS-SSD-Sequential-Read,2782.html
>
> Im Schnitt mehr als Faktor 10, bei einzelnen Fabrikaten sogar noch
> deutlich mehr! Das ist jetzt sogar noch drastischer, als ich in
> Erinnerung hatte.
Obiger Benchmark misst die Random-Read Performance von einer linear
in FS-Sektoren liegenden Datei. Da die linear geschrieben wurde, wird
die SSD diese sehr wahrscheinlich die 4K-Sektoren auch linear in
Flash-Blöcke (512KB z.B.) geschrieben haben. Für jeden Random 4KB Read
muss also ein anderer Flash-Block gelesen werden. -> Minimale
Lese-Performance.
Eine Datei, die fragmentiert im Dateisystem liegt, aber linear geschrieben
wurde, liegt ebenso linear in Flash-Blöcken. Lesen geht daher mit voller
Geschwindigkeit, mal davon angesehen, dass statt eines großes Read-Kommandos
viele kleine gemacht werden müssen. Dank NCQ bremst das aber nicht besonders.
Hendrik vdH
Martin Schoenbeck
Sep 2, 2013, 4:08:46 AM9/2/13
to
Hallo Hergen,
Hergen Lehmann schrieb:
Hergen Lehmann schrieb:
>>> Und auch der Datendurchsatz der SATA-Schnittstelle sinkt bei Random-Read
>>> sp�rbar gegen�ber Sequential-Read.
>>
>> Erz�hl: wie kommst Du auf diese absurde Idee?
>
> Vorsicht, Herr Doktor. Vielleicht schauen sie doch mal besser nach,
> bevor sie die Klappe aufreissen:
>
> http://www.tomshardware.com/charts/ssd-charts-2012/AS-SSD-4K-Random-Read,2784.html
> http://www.tomshardware.com/charts/ssd-charts-2012/AS-SSD-Sequential-Read,2782.html
Und diese Tests hat er direkt an der Schnittstelle mit einer Software
>>> sp�rbar gegen�ber Sequential-Read.
>>
>> Erz�hl: wie kommst Du auf diese absurde Idee?
>
> Vorsicht, Herr Doktor. Vielleicht schauen sie doch mal besser nach,
> bevor sie die Klappe aufreissen:
>
> http://www.tomshardware.com/charts/ssd-charts-2012/AS-SSD-4K-Random-Read,2784.html
> http://www.tomshardware.com/charts/ssd-charts-2012/AS-SSD-Sequential-Read,2782.html
gemacht, von der sichergestellt ist, da� sie ausschlie�lich durch
Unzul�nglichkeiten der Schnittstelle hier Unterschiede mi�t? Sag mal, wovon
tr�umst Du nachts? Vielleicht gibt es ja tats�chlich me�bare
Performanceunterschiede, aber _so_ stellt man allenfalls Unterschiede im
Gesamtsystem fest, aber nicht Schnittstellenprobleme.
Hergen Lehmann
Sep 2, 2013, 3:25:48 PM9/2/13
to
On 02.09.2013 09:02, Hendrik van der Heijden wrote:
> Flash-Bl�cke (512KB z.B.) geschrieben haben. F�r jeden Random 4KB Read
der Flash-Chips durch den Controller erfolgt im Nanosekunden-Bereich.
Dies best�tigt auch ein weiterer Test bei voller NCQ-Warteschlange
(http://www.tomshardware.com/charts/ssd-charts-2012/AS-SSD-4K-Q64-Random-Read,2786.html),
wo es trotz Random Read pl�tzlich wieder deutlich schneller geht (wenn
auch immer noch nicht so schnell wie bei Sequential-Read).
Die Bremse ist hier tats�chlich das SATA-Protokoll, welches zwar beim
eigentlichen Datentransfer schnell ist, aber beim Handshake sehr viel
Zeit vertr�delt. Nicht umsonst verwendet man bei dicken Servern, wo es
auf maximale IOPS ankommt, lieber SAS...
> Eine Datei, die fragmentiert im Dateisystem liegt, aber linear geschrieben
> wurde,
Warum sollte ausgerechnet eine linear geschriebene Datei stark
fragmentiert sein? Praktisch alle modernen Dateisysteme bem�hen sich mit
allerhand Tricks, genau das zu vermeiden!
Nein, wenn eine Datei tats�chlich stark fragmentiert ist, dann wurde sie
entweder *nicht* linear geschrieben oder aber das Medium war randvoll
(was man bei SSD eh vermeiden soll).
> Geschwindigkeit, mal davon angesehen, dass statt eines gro�es Read-Kommandos
> viele kleine gemacht werden m�ssen. Dank NCQ bremst das aber nicht besonders.
NCQ setzt voraus, dass das Betriebssystem bereits weiss, welche Bl�cke
demn�chst ben�tigt werden. Das ist bei starker Fragmentierung gerade
nicht der Fall. Hier muss immer wieder Pause eingelegt und auf den
Inhalt von Verwaltungsbl�cken gewartet werden, bevor die n�chsten
Read-Kommandos abgesetzt werden k�nnen.
Hergen
> Flash-Bl�cke (512KB z.B.) geschrieben haben. F�r jeden Random 4KB Read
> muss also ein anderer Flash-Block gelesen werden. -> Minimale
> Lese-Performance.
Da kann es eigentlich keinen Zusammenhang geben, denn die Adressierung
> Lese-Performance.
der Flash-Chips durch den Controller erfolgt im Nanosekunden-Bereich.
Dies best�tigt auch ein weiterer Test bei voller NCQ-Warteschlange
(http://www.tomshardware.com/charts/ssd-charts-2012/AS-SSD-4K-Q64-Random-Read,2786.html),
wo es trotz Random Read pl�tzlich wieder deutlich schneller geht (wenn
auch immer noch nicht so schnell wie bei Sequential-Read).
Die Bremse ist hier tats�chlich das SATA-Protokoll, welches zwar beim
eigentlichen Datentransfer schnell ist, aber beim Handshake sehr viel
Zeit vertr�delt. Nicht umsonst verwendet man bei dicken Servern, wo es
auf maximale IOPS ankommt, lieber SAS...
> Eine Datei, die fragmentiert im Dateisystem liegt, aber linear geschrieben
> wurde,
fragmentiert sein? Praktisch alle modernen Dateisysteme bem�hen sich mit
allerhand Tricks, genau das zu vermeiden!
Nein, wenn eine Datei tats�chlich stark fragmentiert ist, dann wurde sie
entweder *nicht* linear geschrieben oder aber das Medium war randvoll
(was man bei SSD eh vermeiden soll).
> Geschwindigkeit, mal davon angesehen, dass statt eines gro�es Read-Kommandos
> viele kleine gemacht werden m�ssen. Dank NCQ bremst das aber nicht besonders.
NCQ setzt voraus, dass das Betriebssystem bereits weiss, welche Bl�cke
demn�chst ben�tigt werden. Das ist bei starker Fragmentierung gerade
nicht der Fall. Hier muss immer wieder Pause eingelegt und auf den
Inhalt von Verwaltungsbl�cken gewartet werden, bevor die n�chsten
Read-Kommandos abgesetzt werden k�nnen.
Hergen
Hendrik van der Heijden
Sep 2, 2013, 3:59:22 PM9/2/13
to
Am 02.09.2013 21:25, schrieb Hergen Lehmann:
> On 02.09.2013 09:02, Hendrik van der Heijden wrote:
>> Eine Datei, die fragmentiert im Dateisystem liegt, aber linear geschrieben
>> wurde,
>
> Warum sollte ausgerechnet eine linear geschriebene Datei stark
> fragmentiert sein?
Mal diesen unwahrscheinlichen Fall angenommen. Genau un diesen Fall
> On 02.09.2013 09:02, Hendrik van der Heijden wrote:
>> Eine Datei, die fragmentiert im Dateisystem liegt, aber linear geschrieben
>> wurde,
>
> Warum sollte ausgerechnet eine linear geschriebene Datei stark
> fragmentiert sein?
ging's bei OP.
> Praktisch alle modernen Dateisysteme bem�hen sich mit allerhand Tricks, genau
> das zu vermeiden!
> Nein, wenn eine Datei tats�chlich stark fragmentiert ist, dann wurde sie
> entweder *nicht* linear geschrieben oder aber das Medium war randvoll
extremer) Fragmentierungs- und F�llgrad erreicht ist, und Dateien zwar linear,
aber nicht mit einem gro�en sondern vielen kleinen Schreibbefehlen erzeugt wird.
Hab da so ne Inhouse-Software, die schreibt 20MB Bild-Dateien mit Vorliebe
in 297 Fragmenten. Auch wenn linear noch woanders 20GB frei w�ren.
Hendrik vdH.
Hergen Lehmann
Sep 2, 2013, 4:33:28 PM9/2/13
to
On 02.09.2013 21:59, Hendrik van der Heijden wrote:
>> Warum sollte ausgerechnet eine linear geschriebene Datei stark
>> fragmentiert sein?
>
> Mal diesen unwahrscheinlichen Fall angenommen. Genau un diesen Fall
> ging's bei OP.
Der OP hat sich nie ge�u�ert, was in welcher Form auf der Platte
>> Warum sollte ausgerechnet eine linear geschriebene Datei stark
>> fragmentiert sein?
>
> Mal diesen unwahrscheinlichen Fall angenommen. Genau un diesen Fall
> ging's bei OP.
gespeichert ist.
>> Nein, wenn eine Datei tats�chlich stark fragmentiert ist, dann wurde sie
>> entweder *nicht* linear geschrieben oder aber das Medium war randvoll
>
> Zumindest XP stellt sich ziemlich bl�d an, wenn ein gewisser (aber keineswegs
Stand der Technik... ;)
> extremer) Fragmentierungs- und F�llgrad erreicht ist, und Dateien zwar linear,
> aber nicht mit einem gro�en sondern vielen kleinen Schreibbefehlen erzeugt wird.
> Hab da so ne Inhouse-Software, die schreibt 20MB Bild-Dateien mit Vorliebe
> in 297 Fragmenten. Auch wenn linear noch woanders 20GB frei w�ren.
Der formale Aufbau der g�ngigen Bilddatei-Formate ermuntert dazu, die
einzelnen Chunks (Header, Bilddaten, Metainformationen) nicht unbedingt
in sequentieller Reihenfolge zu schreiben. Das gibt dann nat�rlich
beinahe zwangsl�ufig Fragmente.
Weiterhin gibt es in der Windows-API einen Systemaufruf
(SetFileInformationByHandle, Parameter FileAllocationInfo), mit dem man
Allokations-Algorithmus unter die Arme greifen und bereits vorab
Plattenplatz f�r eine Datei reservieren kann.
Hergen
Hendrik van der Heijden
Sep 2, 2013, 5:20:03 PM9/2/13
to
Am 02.09.2013 22:33, schrieb Hergen Lehmann:
> On 02.09.2013 21:59, Hendrik van der Heijden wrote:
>> Hab da so ne Inhouse-Software, die schreibt 20MB Bild-Dateien mit Vorliebe
>> in 297 Fragmenten. Auch wenn linear noch woanders 20GB frei w�ren.
>
> Kann auch eine ungeschickte Programmierung sein.
>
> Der formale Aufbau der g�ngigen Bilddatei-Formate ermuntert dazu, die
> einzelnen Chunks (Header, Bilddaten, Metainformationen) nicht unbedingt
> in sequentieller Reihenfolge zu schreiben. Das gibt dann nat�rlich
> beinahe zwangsl�ufig Fragmente.
Doch, ich hab den Source gesehen. Wird sequentiell geschrieben in ~6 KB-Bl�ckchen.
> On 02.09.2013 21:59, Hendrik van der Heijden wrote:
>> Hab da so ne Inhouse-Software, die schreibt 20MB Bild-Dateien mit Vorliebe
>> in 297 Fragmenten. Auch wenn linear noch woanders 20GB frei w�ren.
>
> Kann auch eine ungeschickte Programmierung sein.
>
> Der formale Aufbau der g�ngigen Bilddatei-Formate ermuntert dazu, die
> einzelnen Chunks (Header, Bilddaten, Metainformationen) nicht unbedingt
> in sequentieller Reihenfolge zu schreiben. Das gibt dann nat�rlich
> beinahe zwangsl�ufig Fragmente.
> Weiterhin gibt es in der Windows-API einen Systemaufruf
> (SetFileInformationByHandle, Parameter FileAllocationInfo), mit dem man
> Allokations-Algorithmus unter die Arme greifen und bereits vorab
> Plattenplatz f�r eine Datei reservieren kann.
Hendrik vdH
0 new messages