SSD mit CHKDSK und DEFRAG
Reinhard Brücken
Defrag k�nnte ja eigentlich entbehrlich sein.
Wie ist eure Meinung? Habt ihr schon Erfahrungen hiermit gemacht?
Gr��e
Reinhard
DGrade
news:7oh63nF...@mid.individual.net...
> Ist es ratsam auch bei SSD's gelegentlich chkdsk und defrag zu benutzen?
> Defrag k�nnte ja eigentlich entbehrlich sein.
Auf keinen Fall nutzen! Du "verbr�tst" damit nur die chips.
> Wie ist eure Meinung? Habt ihr schon Erfahrungen hiermit gemacht?
Ja, ist schon "ungewohnt" nicht mehr defraggen zu m�ssen/d�rfen,
aber wenns halt so geschrieben steht, sollte man es auch so handhaben.
> Gr��e
> Reinhard
Gruzz,
Danny
Martin Wohlauer
> "Reinhard Br�cken" <rei...@web.de> schrieb im Newsbeitrag
> news:7oh63nF...@mid.individual.net...
>> Ist es ratsam auch bei SSD's gelegentlich chkdsk und defrag zu benutzen?
> chkdsk? Wozu? Welche Oberfl�che sollte hier schadhaft werden :-)
Das Dateisystem aber, oder checkt chkdsk neuerdings nur noch die Oberfl�che?
Gr��le,
Martin.
Hergen Lehmann
>> Ist es ratsam auch bei SSD's gelegentlich chkdsk und defrag zu benutzen?
> chkdsk? Wozu? Welche Oberfl�che sollte hier schadhaft werden :-)
chkdsk pr�ft nicht die Oberfl�che (die eigentlichen Dateiinhalte werden
gar nicht gelesen!), sondern die Integrit�t des Dateisystems. Und das
ist auch auf Flash-Medien �beraus sinnvoll, besonders falls man noch
"antikes" wie FAT nutzt.
>> Defrag k�nnte ja eigentlich entbehrlich sein.
> Auf keinen Fall nutzen! Du "verbr�tst" damit nur die chips.
Halte ich f�r �bertrieben. Die Belastung durch eine gelegentliche
Defragmentierung wird geringer sein, als die durch eine t�glich genutze
Applikation, die immer wieder die selben Dateien �berschreibt (wie z.B.
einen Newsreader ;).
Der Nutzen einer Defragmentierung d�rfte allerdings ebenfalls gering und
nur bei extrem fragmentierten Medien �berhaupt messbar sein.
Hergen
Thomas Neumann
>>> Defrag k�nnte ja eigentlich entbehrlich sein.
>> Auf keinen Fall nutzen! Du "verbr�tst" damit nur die chips.
>
> Halte ich f�r �bertrieben. Die Belastung durch eine gelegentliche
> Defragmentierung wird geringer sein, als die durch eine t�glich genutze
> Applikation, die immer wieder die selben Dateien �berschreibt (wie z.B.
> einen Newsreader ;).
Irgendwo (Halbwissen), habe ich aufgeschnappt das der Controller auf SSD
sowieso selbst entscheidet wo Daten abgelegt werden. Die Dateien w�rden
somit st�ndig in anderen Speicherzellen landen. Das soll verhindern, dass
es einzelne Bereiche gibt die erheblich mehr Schreibzyklen aufweisen als
andere.
Thomas N.
Marcel Müller
Thomas Neumann wrote:
> Irgendwo (Halbwissen), habe ich aufgeschnappt das der Controller auf SSD
> sowieso selbst entscheidet wo Daten abgelegt werden. Die Dateien w�rden
> somit st�ndig in anderen Speicherzellen landen. Das soll verhindern, dass
> es einzelne Bereiche gibt die erheblich mehr Schreibzyklen aufweisen als
> andere.
das Halbwissen stimmt, und sp�testens aus diesem Grund ist eine
Defragmentierung zu 100,0% nutzlos. Daraus folgt aber nicht, dass sie
keinen Schaden anrichten kann.
Also wie Danny schrieb: lassen!
Marcel
Hergen Lehmann
> Irgendwo (Halbwissen), habe ich aufgeschnappt das der Controller auf SSD
> sowieso selbst entscheidet wo Daten abgelegt werden. Die Dateien w�rden
> somit st�ndig in anderen Speicherzellen landen. Das soll verhindern, dass
> es einzelne Bereiche gibt die erheblich mehr Schreibzyklen aufweisen als
> andere.
Genau. Daher ist die Belastung durch eine Defragmentierung
wahrscheinlich auch nicht h�her, als durch normalen Schreibbetrieb.
"Wahrscheinlich" deshalb, weil die genaue Arbeitsweise (und damit auch
die Wirksamkeit) des Wear-Leveling von den Controllerherstellern als
Betriebsgeheimnis geh�tet wird.
Ich w�rd's vorsichtshalber nicht regelm�ssig machen, sondern wirklich
nur dann, wenn ein Medium ganz extrem fragmentiert ist.
Hergen
Thomas Neumann
> Ich w�rd's vorsichtshalber nicht regelm�ssig machen, sondern wirklich
> nur dann, wenn ein Medium ganz extrem fragmentiert ist.
Welchen Vorteil hat dann das Defragmentieren auf SSD?
Thomas N.
Norbert Hahn
>DGrade schrieb:
>
>>> Ist es ratsam auch bei SSD's gelegentlich chkdsk und defrag zu benutzen?
>> chkdsk? Wozu? Welche Oberfl�che sollte hier schadhaft werden :-)
>
>chkdsk pr�ft nicht die Oberfl�che (die eigentlichen Dateiinhalte werden
>gar nicht gelesen!), sondern die Integrit�t des Dateisystems.
Dateiinhalte und auch der leere Bereich einer Platte kann selbst-
verst�ndlich mit chkdsk gepr�ft werden. Da das aber erhebliche Zeit
ben�tigt, ist die Voreinstellung, keine Datenbereiche zu lesen.
>Und das
>ist auch auf Flash-Medien �beraus sinnvoll, besonders falls man noch
>"antikes" wie FAT nutzt.
Allerdings.
Norbert
Harald Klotz
>> Ich w�rd's vorsichtshalber nicht regelm�ssig machen, sondern
>> wirklich nur dann, wenn ein Medium ganz extrem fragmentiert ist.
>
> Welchen Vorteil hat dann das Defragmentieren auf SSD?
Einfaches wiederherstellen versehentlich gel�schter Dateien.
Harald
Robert Kochem
> Der Nutzen einer Defragmentierung d�rfte allerdings ebenfalls gering und
> nur bei extrem fragmentierten Medien �berhaupt messbar sein.
Je nach Contrioller-Typ in der SSD und dem Wear-Level-Algorithmus d�rfte
man manchmal ganz sch�n die Auswirkungen bemerken - nur leider sind diese
negativ!
Da beim Defragmentieren nahezu jeder Block der Festplatte durch die Gegend
geschoben wird hat der Wear-Leveling-Algo immer mehr m�he mit der
Verwaltung hinterher zu kommen. Bei einigen SSDs macht sich das schon im
normalen Betrieb bemerkbar und eine Defragmentierung versch�rft dieses
Problem noch.
Nicht ohne Grund schaltet Windows 7, wenn es auf eine SSD installiert wird
alle automatischen Defrag-Optimierungen aus...
Robert
Richard W. Könning
>Ich w�rd's vorsichtshalber nicht regelm�ssig machen, sondern wirklich
>nur dann, wenn ein Medium ganz extrem fragmentiert ist.
Was soll das bringen? Solange diese Aktion keinen Nutzen, aber Schaden
bringt (auch wenn letzterer sich in Grenzen h�lt), gibt es keinen
Anla� f�r eine Defragmentierung. Ich habe den Eindruck, da� f�r manche
Leute eine Defragmentierung schon fast so etwas wie ein religi�ses
Ritual ist.
Ciao,
Richard
--
Dr. Richard K�nning He�stra�e 63
Tel.: 089/5232488 80798 M�nchen
Enrico Dörre
> Halte ich f�r �bertrieben. Die Belastung durch eine gelegentliche
> Defragmentierung wird geringer sein, als die durch eine t�glich genutze
> Applikation, die immer wieder die selben Dateien �berschreibt (wie z.B.
> einen Newsreader ;).
> Der Nutzen einer Defragmentierung d�rfte allerdings ebenfalls gering und
> nur bei extrem fragmentierten Medien �berhaupt messbar sein.
Und Du meinst das es f�r die Platte einen Unterschied macht ob sie die
Daten nach dem Block 00001 vom folgenden Block 00010 liest statt von
10010 oder 01011? Das halte ich aber f�r ein Ger�cht, die Adresse mu�
�bertragen werden, damit ist die genaue Lage vollkommen egal.
Klar bei einer "normalen" HDD ist das etwas anders, da mu� der Kopf
bewegt werden, dann mu� der Kopf warten bis die Daten wieder
vorbeikommen damit er lesen kann. Klar dauert das, aber das ist durch
die Mechanik begr�ndet.
Bei einer SSD bestimmt eh die HDD selbst wohin sie die Daten scheibt.
Mich wundert das man bei einer SSD �berhaupt sehen kann wo die Daten
liegen, wei� da zuf�llig jemand ob die angezeigte Lage im
Defragmentierungsprogramm mit der Lage der Speicherzellen �bereinstimmt?
Gr��e
Enrico
Reinhard Brücken
Ich danke euch f�r die umfassenden Meinungen und Ratschl�ge. Ich bin
gespannt, wielange die SSD h�lt.
Gr��e
Reinhard
Hergen Lehmann
> Und Du meinst das es f�r die Platte einen Unterschied macht ob sie die
> Daten nach dem Block 00001 vom folgenden Block 00010 liest statt von
> 10010 oder 01011?
Ja, es macht einen erheblichen Unterschied, ob das Filesystem die Daten
fortlaufend als Multi-Sektor-Read von 0-1000 lesen kann oder es hunderte
einzelner Lesebefehle auf verstreute Sektoren absetzen muss, garniert
noch mit weiteren Zugriffen auf Verwaltungsstrukturen, um �berhaupt
rauszufinden, wo es weiter geht.
Jerhem
Hergen Lehmann
>> nur dann, wenn ein Medium ganz extrem fragmentiert ist.
>
> Welchen Vorteil hat dann das Defragmentieren auf SSD?
1. Auf einem stark fragmentierten Medium kann das Filesystem grosse
Dateien nicht mehr in Form von Extents verwalten, was sp�testens bei
wahlfreiem Zugriff (Datenbanken!) deutlichen Overhead verursacht.
2. Fragmentierte Dateien kann das Filesystem nicht mehr fortlaufend mit
Multi-Sektor-Befehlen lesen/schreiben, sondern muss h�ufig absetzen,
durch eingeschobene Zugriffe die Fortsetzung suchen, und neue Kommandos
senden. Sollte bei Streaming durchaus sp�rbar sein.
3. Flash-Speicher kann nicht sektorweise beschrieben werden, sondern nur
in Form gr�sserer Bl�cke. Bei Schreiben in stark fragmentierte Dateien
werden somit umfangreichere Schreiboperationen f�llig, als beim
sequentiellen Schreiben auf ein unfragmentiertes Medium. Auch das wird
man merken, zumal Flash gerade beim Schreiben schw�chelt.
Wohlgemerkt: Ich rede hier von *EXTREMER* Fragmentierung mit tausenden
Fragmenten in einer Datei, wie sie etwa auftritt, wenn eine Datenbank
�ber Monate langsam gewachsen ist oder man grosse Dateien auf ein
fragmentiertes, bereits recht volles Medium schreibt.
Das M�rchen von angeblich fragmentierungssicheren Filesystemen und
Medien ist genauso Bl�dsinn, wie die t�gliche Durchf�hrung einer
Defragmentierung als religi�ser Akt...
Hergen
Richard W. Könning
Ich habe meine Zweifel, ob es einen *erheblichen* Unterschied macht.
Und Anwendungen, dir nicht gerade vom Typ "Kopierprogramm" sind,
werden auch eher selten 1000 Sektoren auf einem Schlag lesen.
Marcel Müller
Diese Denkmuster sind seit NTFS nicht mehr zeitgem��. Undelete unter
NTFS ist auch bei beliebigem Fragmentierungsgrad zuverl�ssig, solange
die beteiligten Bl�cke noch nicht physisch �berschrieben wurden.
Und wer meint FAT32 benutzen zu m�ssen, hat entweder einen sehr guten
Grund jenseits der �blichen Anforderungen an einen PC oder immer noch
nicht genug Daten verloren.
Marcel
Marcel Müller
Hergen Lehmann wrote:
>>> Ich w�rd's vorsichtshalber nicht regelm�ssig machen, sondern wirklich
>>> nur dann, wenn ein Medium ganz extrem fragmentiert ist.
>>
>> Welchen Vorteil hat dann das Defragmentieren auf SSD?
>
> 1. Auf einem stark fragmentierten Medium kann das Filesystem grosse
> Dateien nicht mehr in Form von Extents verwalten, was sp�testens bei
> wahlfreiem Zugriff (Datenbanken!) deutlichen Overhead verursacht.
? - Wie sonst als in Extents soll NTFS fragmentierte Dateien verwalten?
(Ich vermute es war etwas anders gemeint.)
> 2. Fragmentierte Dateien kann das Filesystem nicht mehr fortlaufend mit
> Multi-Sektor-Befehlen lesen/schreiben, sondern muss h�ufig absetzen,
> durch eingeschobene Zugriffe die Fortsetzung suchen, und neue Kommandos
> senden. Sollte bei Streaming durchaus sp�rbar sein.
Aber nicht mit Streaming ins Netz verwechseln. Man braucht schon mehr
als GBit-LAN, damit der Kommando-Overhead beim linearen Lesen das
Ergebnis signifikant beeinflusst. Ich meine da m�sste schon bald jeder
4k-Block einzeln irgendwo herumliegen, um bei 10MB/s abzuregeln. Einen
solchen Fragmentierungsgrad habe ich noch bei keinem Dateisystem erlebt.
Lokale Disk-zu-Disk Kopien k�nnen nat�rlich leichter einbrechen, denn da
sind bei linearen Transfers zwischen unterschiedlichen physischen
Platten auch mal 100MB/s drin.
> 3. Flash-Speicher kann nicht sektorweise beschrieben werden, sondern nur
> in Form gr�sserer Bl�cke. Bei Schreiben in stark fragmentierte Dateien
> werden somit umfangreichere Schreiboperationen f�llig, als beim
> sequentiellen Schreiben auf ein unfragmentiertes Medium. Auch das wird
> man merken, zumal Flash gerade beim Schreiben schw�chelt.
Da das Mapping der logischen Sektoren auf physische Bl�cke im Flash der
Firmware der SSD obliegt, zieht dieses Argument wohl kaum. Sprich, die
SSDs werden sowieso nicht Blockweise beschrieben. Das w�re auch ziemlich
konstruiert bei ca. 128k Blockgr��e von billigem MLC-Flash.
Anders formuliert: die SSDs versuchen aufeinanderfolgende
Schreibzugriffe unabh�ngig von den betroffenen Sektoren auf
zusammenh�ngende physische Bereiche abzubilden. Hei�t das Mapping �ndert
sich st�ndig. Genau an diesem Punkt greift auch das Wear-Leveling mit an.
> Wohlgemerkt: Ich rede hier von *EXTREMER* Fragmentierung mit tausenden
> Fragmenten in einer Datei, wie sie etwa auftritt, wenn eine Datenbank
> �ber Monate langsam gewachsen ist oder man grosse Dateien auf ein
> fragmentiertes, bereits recht volles Medium schreibt.
Selbst das d�rfte nicht reichen, um signifikante Einbussen zu erzielen,
denn kaum eine DB wird in 4k-Bl�cken wachsen. Au�erdem muss auch sch�n
brav zwischen die DB-Blocks anderer Kram geschrieben werden, sonst
st�ckelt NTFS erstmal beim letzten Extent an. Wenn das passiert, hat der
DB-Admin aber seine Arbeit auch nicht wirklich gut gemacht, z.B. DB und
Logfiles auf einem Volume. Es gibt nat�rlich ein paar simple
Datenbanken, die sich recht dumm anstellen, weil sie jede Tabelle und
jeden Index als eigenes File f�hren.
Aber mal im ernst, gegen�ber der Performancekatastrophe, die selbiger
Fragmentierungszustand auf realen, rotierenden Festplatten verursacht,
sind die Auswirkungen bei der SSD doch Peanuts.
Im �brigen ist die Anzahl der Fragmente einer Datei kein guter Parameter
f�r den Fragmentierungsgrad. Anzahl Fragmente minus eins, geteilt durch
Dateigr��e ist ein besserer Parameter. Wobei die Summe �ber das Volume
betrachtet werden muss, also: (Anzahl Fragmente - Anzahl Dateien) /
belegten Platz. Je h�her, desto schlimmer ist es.
Anders gesagt, kleine fragmentierte Dateien sind viel schlimmer als
gro�e. Umgekehrt geht aber kleine Files defragmentieren viel einfacher
als gro�e.
> Das M�rchen von angeblich fragmentierungssicheren Filesystemen und
> Medien ist genauso Bl�dsinn, wie die t�gliche Durchf�hrung einer
> Defragmentierung als religi�ser Akt...
Da ist schon was dran. Aber IBM hat seinerzeit mit HPFS ziemlich gut
vorgelegt. Damit sind mehrere Jahre Desktopbetrieb ohne nennenswert
ansteigenden Fragmentierungsgrad definitiv drin. Vor allem auf Medien
mit extrem schlechten Zugriffszeiten (z.B. Rewritables) wirkt das auch
heute noch Wunder.
NTFS ist (vmtl. aus Gr�nden der Skalierbarkeit) anders ausgelegt. Diese
Optimierungsalgorithmen skalieren n�mlich oft linear im RAM und
zumindest logarithmisch in der CPU. Damit bekommt man keine xxTB
Dateisysteme performant geschaukelt.
Marcel
Shinji Ikari
Marcel M嚙締ler <news.5...@spamgourmet.com> schrieb
>>>> Ich w嚙緝d's vorsichtshalber nicht regelm嚙編sig machen, sondern
>>>> wirklich nur dann, wenn ein Medium ganz extrem fragmentiert ist.
>>> Welchen Vorteil hat dann das Defragmentieren auf SSD?
>> Einfaches wiederherstellen versehentlich gel嚙編chter Dateien.
>Diese Denkmuster sind seit NTFS nicht mehr zeitgem嚙踝蕭. Undelete unter
>NTFS ist auch bei beliebigem Fragmentierungsgrad zuverl嚙編sig, solange
>die beteiligten Bl嚙箱ke noch nicht physisch 嚙箭erschrieben wurden.
...sofern die Anzahl der geloeschten und durch ein solches Tool
gefunden Dateien nicht sehr gross ist. Vor wenigen Tagen versuche ich
auf einer Festplatte ein versehentlich geloeschtes RAR-Archiv wieder
herzustellen. Ich habe das Avira Unerase (oder war es undelete?)
genommen. es fand rund 92000 geloeschte Dateien. allein die Sortierung
in dem tool (um die gewuenschte Datei wieder zu finden) dauerte >20
Minuten.
Gelegentliches Defragmentieren (oder auch Nullen) einer
HDD/SDD/Datentraeger kann bei spaeterem Loeschen die Anzahl der
gefunden geloeschten Dateien reduzieren und somit eine
Wiederherstellung beschleunigen.
>Und wer meint FAT32 benutzen zu m嚙編sen, hat entweder einen sehr guten
>Grund jenseits der 嚙箭lichen Anforderungen an einen PC oder immer noch
>nicht genug Daten verloren.
Ich nutze weiterhin gerne FAT32 als Bootpartition, weil mir dann das
Windows nicht mit seinen Berechtigungen in die Quere kommt.
Harald Klotz
> Und wer meint FAT32 benutzen zu m�ssen, hat entweder einen sehr
> guten Grund jenseits der �blichen Anforderungen an einen PC oder
> immer noch nicht genug Daten verloren.
Standard bei Speichersticks und Kameraspeicher ist FAT.
Harald
Hergen Lehmann
Leider! Das �ndert aber nichts an der Tatsache, da� FAT mangels
Journaling (und auch wegen der zentralistischen Organisation der
Verwaltungsdaten) in Sachen Datensicherheit eine sehr schlechte Wahl
darstellt.
Wo immer man die Wahl hat, sollte man dringend was Moderneres nehmen.
Hergen
Robert Kochem
> Standard bei Speichersticks und Kameraspeicher ist FAT.
Gl�cklicherweise nicht mehr lange. Mit Einf�hrung der SDXC-Karten und dem
fest vorgeschriebenen FatEx d�rfte das Anfang vom Ende von FAT32
eingeleutet sein.
Robert
Shinji Ikari
Robert Kochem <rob...@mailueberfall.de> schrieb
>Gl�cklicherweise nicht mehr lange. Mit Einf�hrung der SDXC-Karten und dem
>fest vorgeschriebenen FatEx d�rfte das Anfang vom Ende von FAT32
>eingeleutet sein.
Wenn sich jetzt noch Linux, Mac, Windows und ein paar kleinere
Spartensysteme einig werden....
Michael Baeuerle
> Robert Kochem <rob...@mailueberfall.de> schrieb
> >
> > Gl�cklicherweise nicht mehr lange. Mit Einf�hrung der SDXC-Karten und dem
> > fest vorgeschriebenen FatEx d�rfte das Anfang vom Ende von FAT32
> > eingeleutet sein.
MS wird sich freuen, da haben sie das Rad neu erfunden, patentiert
bekommen und jetzt koennen sie wieder Geld verdienen mit etwas dessen
Funktionalitaet man seit Jahren auch umsonst bekommt. Wie sie das immer
wieder schaffen ist bewundernswert. Da haben sie bei SDXC wohl auch das
Standardisierungsgremium beeinflusst so wie seinerzeit bei ODF vs OOXML.
> Wenn sich jetzt noch Linux, Mac, Windows und ein paar kleinere
> Spartensysteme einig werden....
Daran sind MS und Apple wohl nicht interessiert, s.o.
Micha
Marcel Müller
Shinji Ikari wrote:
>> Undelete unter
>> NTFS ist auch bei beliebigem Fragmentierungsgrad zuverl�ssig, solange
>> die beteiligten Bl�cke noch nicht physisch �berschrieben wurden.
>
> ...sofern die Anzahl der geloeschten und durch ein solches Tool
> gefunden Dateien nicht sehr gross ist. Vor wenigen Tagen versuche ich
> auf einer Festplatte ein versehentlich geloeschtes RAR-Archiv wieder
> herzustellen. Ich habe das Avira Unerase (oder war es undelete?)
> genommen. es fand rund 92000 geloeschte Dateien. allein die Sortierung
> in dem tool (um die gewuenschte Datei wieder zu finden) dauerte >20
> Minuten.
ist doch nicht schlimm. Ist doch gut, dass sie �berhaupt wieder da war.
Genauso gut h�tte sie teilweise von irgendwelchen Temp-Files
�berschrieben sein k�nnen.
Ich meine das wird doch nicht Teil eines sich wiederholenden normalen
Prozesses, auf den man regelm��ig wartet. Und wenn es hart auf hart
kommt, muss man halt mal das Backup rauskramen. Das geht u.U. sogar
deutlich schneller.
> Gelegentliches Defragmentieren (oder auch Nullen) einer
> HDD/SDD/Datentraeger kann bei spaeterem Loeschen die Anzahl der
> gefunden geloeschten Dateien reduzieren und somit eine
> Wiederherstellung beschleunigen.
Das dauert aber auch 20 Minuten und kommt �fter vor.
>> Und wer meint FAT32 benutzen zu m�ssen, hat entweder einen sehr guten
>> Grund jenseits der �blichen Anforderungen an einen PC oder immer noch
>> nicht genug Daten verloren.
>
> Ich nutze weiterhin gerne FAT32 als Bootpartition, weil mir dann das
> Windows nicht mit seinen Berechtigungen in die Quere kommt.
? - Ich hatte im Leben noch keine Probleme mit den Berechtigungen auf
dem Bootlaufwerk. Ich meine die administrativen Berechtigungen sind ja
sogar unabh�ngig von der SID.
Im Gegenteil. Die Berechtigungen verhindern recht effektiv, dass
irgendein Gast/Test-Account gleich alles zersemmelt oder man
versehentlich mal wieder mit dem Explorer die 20. Funktion auf der
linken Maustaste aktiviert und irgendetwas essentielles dahin
verschiebt, wo es nicht hin geh�rt - vor allem mit Touchpads. (IBM war
da irgendwie seinerzeit heller im Kopf, indem sie keine unmittelbar
modifizierenden Operationen auf die linke Taste gelegt haben, mit der
man dauernd selektiert.)
Aber der Hauptgrund, warum ich es nie f�r ein Systemlaufwerk nehmen
w�rde, ist dass es nach einem Crash extrem subtile Fehler produzieren
kann (vor allem bei Cross-Links).
Marcel
Thomas Rachel
> Harald Klotz schrieb:
>
>> Standard bei Speichersticks und Kameraspeicher ist FAT.
>
> fest vorgeschriebenen FatEx dürfte das Anfang vom Ende von FAT32
> eingeleutet sein.
Was hat ein proprietäres Verfahren wie FatEx mit "glücklicherweise" zu tun?
Thomas
Shinji Ikari
Marcel M锟絣ler <news.5...@spamgourmet.com> schrieb
>>>> Einfaches wiederherstellen versehentlich gel锟絪chter Dateien.
>>>Diese Denkmuster sind seit NTFS nicht mehr zeitgem锟斤拷. Undelete unter
>>>NTFS ist auch bei beliebigem Fragmentierungsgrad zuverl锟絪sig, solange
>>>die beteiligten Bl锟絚ke noch nicht physisch 锟絙erschrieben wurden.
>> ...sofern die Anzahl der geloeschten und durch ein solches Tool
>> gefunden Dateien nicht sehr gross ist. Vor wenigen Tagen versuche ich
>> auf einer Festplatte ein versehentlich geloeschtes RAR-Archiv wieder
>> herzustellen. Ich habe das Avira Unerase (oder war es undelete?)
>> genommen. es fand rund 92000 geloeschte Dateien. allein die Sortierung
>> in dem tool (um die gewuenschte Datei wieder zu finden) dauerte >20
>> Minuten.
>ist doch nicht schlimm. Ist doch gut, dass sie 锟絙erhaupt wieder da war.
Eine grosse Zahl der Dateien wurde mit einer nicht grossen Chance der
Wiederherstellung angegeben. Nach der Defragmentierung und Loeschung
der freien Bereiche werden alte Dateien in der Regel nicht
aufgelistet. Somit hat eine nicht durchgefuehrte Defragmentierung die
Wiederherstellung der gesuchten Datei verzoegert + erschwert.
>> Gelegentliches Defragmentieren (oder auch Nullen) einer
>> HDD/SDD/Datentraeger kann bei spaeterem Loeschen die Anzahl der
>> gefunden geloeschten Dateien reduzieren und somit eine
>> Wiederherstellung beschleunigen.
>Das dauert aber auch 20 Minuten und kommt 锟絝ter vor.
Die Defragmentierung und auch ein Nullen kann aber im Hintergrund
laufen und stoert meist weniger als die Zeit, die man tatenlos vor dem
Screen hockt, weil man darauf wartet, das ein Undelete-Programm einem
die richtigen Dateien anbietet und wiederherstellt.
Denn in dem Fall kann/sollte man ja ncht weiter arbeiten, weil die
gesuchten Dateireste dabei wirklich ueberschrieben werden koennten.
>> Ich nutze weiterhin gerne FAT32 als Bootpartition, weil mir dann das
>> Windows nicht mit seinen Berechtigungen in die Quere kommt.
>? - Ich hatte im Leben noch keine Probleme mit den Berechtigungen auf
>dem Bootlaufwerk.
Dann deaktiviere bei laufendem Windows doch 'mal die
Datentraegerindizierung der Bootpartition ("Laufwerk fuer schnelle
Dateisuche indizieren") ueber den Windows-Arbeitsplatz.
Oder versuche ohne besondere Tricks Dateien in "System Volume
Information" einzusehen, manipulieren oder loeschen.
Dirk Ohme
> ...sofern die Anzahl der geloeschten und durch ein
> solches Tool gefunden Dateien nicht sehr gross ist.
Noch ein Grund, warum man regelm��ige Backups fahren sollte ;-)
Gru�, Dirk
Dirk Ohme
> 1. Auf einem stark fragmentierten Medium kann das
> Filesystem grosse Dateien nicht mehr in Form von
> Extents verwalten, was sp�testens bei wahlfreiem
> Zugriff (Datenbanken!) deutlichen Overhead verursacht.
Datenbanken legen �ber "ihre" Datendateien nochmals ein eigenes
Datenverwaltungssystem. Man ist gut beraten, man berechnet vor dem
Anlegen einer Datenbank den Speicherverbrauch und sorgt ggfs. im Laufe
der Zeit f�r eine Datenbankreorganisation, denn das Defragmentieren
der Dateien im Dateisystem ist dann nur die halbe Miete - die interne
Struktur der Datenbank ist nach wie vor fragmentiert!
> 2. Fragmentierte Dateien kann das Filesystem nicht mehr fort-
> laufend mit Multi-Sektor-Befehlen lesen/schreiben [...]
Und das hat bei SSD genau was zur Folge? Hey, bei SSD sind
Spurwechselzeiten vernachl�ssigbar bzw. nicht vorhanden. Da wirkt sich
dann eher aus, ob die Sektorgr��e 512 Byte sein muss oder 2048 Byte
sein darf ...
> 3. Flash-Speicher kann nicht sektorweise beschrieben werden,
> sondern nur in Form gr�sserer Bl�cke.
Weshalb es deutlich mehr Sinn macht, die Sektorgr��e der Blockgr��e
auf dem Flash-Speicher anzupassen, als mit Defragmentierung zu
arbeiten ...
Gru�, Dirk
Shinji Ikari
"Dirk Ohme" <dirk...@hotmail.com> schrieb
>Noch ein Grund, warum man regelm��ige Backups fahren sollte ;-)
Buss, Bahn, Taxi, Auto, Fahrrad fahren kenne ich aber Backup? Sind
die guenstig? 8))
SCNR.
Marcel Müller
Shinji Ikari wrote:
>> ? - Ich hatte im Leben noch keine Probleme mit den Berechtigungen auf
>> dem Bootlaufwerk.
>
> Dann deaktiviere bei laufendem Windows doch 'mal die
> Datentraegerindizierung der Bootpartition ("Laufwerk fuer schnelle
> Dateisuche indizieren") ueber den Windows-Arbeitsplatz.
ist bei mir immer aus. Besonders mit Notebooks (ohne SSD) kann man nicht
ernsthaft arbeiten, wenn der Dienst die Platte immer mal wieder mit
Requests zuspammt.
Kurzum, ich wei� nicht, was mich da B�ses h�tte erwarten sollen?
> Oder versuche ohne besondere Tricks Dateien in "System Volume
> Information" einzusehen, manipulieren oder loeschen.
Naja, Systemwiederherstellung deaktivieren, und schon steht nicht mehr
viel drin, was irgendjemanden interessieren k�nnte. Und ich meine wegen
einem, Verzeichnis, wo ich mir erst die Berechtigung geben muss, wenn
ich unbedingt reingucken m�chte, schmei�e ich doch kein ganzes
Dateisystem �ber Bord und riskiere mit FATxx meine Daten.
Unter FAT bekommt das Thema Undelete �brigens eine noch deutlich
w�rzigere Note, denn es ist dort immanent unzuverl�ssig. Um eine Datei
zuverl�ssig wiederherzustellen, muss man Wissen, dass sie nicht
fragmentiert bzw. nicht von freien Clustern unterbrochen war. Diese
Information geht aber mit dem L�schen unwiederbringlich verloren. Ferner
geht die Dateigr��e hops. Kurzum, die Wiederhergestellten Daten sind
nicht als zuverl�ssig oder unzuverl�ssig zu erkennen. Man braucht eine
Pr�fsumme oder eine 100% Sichtpr�fung je wiederhergestellte Datei. Nur
Dateiformate mit eingebauter Pr�fsumme sind da halbwegs gutm�tig. Mit
heuristischen Verfahren kommt man einigerma�en durch. Aber letztlich
bleibt immer eine Unsicherheit, so k�nnen Fragmente von MPEGs z.B. dabei
z.B. leicht datei�bergreifend vertauscht werden.
Marcel
Shinji Ikari
Marcel M�ller <news.5...@spamgourmet.com> schrieb
>>>> Ich nutze weiterhin gerne FAT32 als Bootpartition, weil mir dann das
>>>> Windows nicht mit seinen Berechtigungen in die Quere kommt.
>>> ? - Ich hatte im Leben noch keine Probleme mit den Berechtigungen auf
>>> dem Bootlaufwerk.
>> Dann deaktiviere bei laufendem Windows doch 'mal die
>> Datentraegerindizierung der Bootpartition ("Laufwerk fuer schnelle
>> Dateisuche indizieren") ueber den Windows-Arbeitsplatz.
>ist bei mir immer aus.
ueber den genannten Weg?
>Kurzum, ich wei� nicht, was mich da B�ses h�tte erwarten sollen?
Eine Meldung, dass die Berechtigungen nicht vorhanden sind.
>> Oder versuche ohne besondere Tricks Dateien in "System Volume
>> Information" einzusehen, manipulieren oder loeschen.
>Naja, Systemwiederherstellung deaktivieren,
Das war nicht die Aufgabe. Deaktivieren ist nicht gleich einsehen oder
manipulieren.
>und schon steht nicht mehr
>viel drin, was irgendjemanden interessieren k�nnte.
Aber so einfach kommt man dennoch nicht ran, weil da eben die
Beschraenkungen im weg stehen.
>Und ich meine wegen
>einem, Verzeichnis, wo ich mir erst die Berechtigung geben muss,
Voila. genau das meinte ich.
Bei Fat32 braucht man das erst gar nicht.
>wenn
>ich unbedingt reingucken m�chte, schmei�e ich doch kein ganzes
>Dateisystem �ber Bord und riskiere mit FATxx meine Daten.
Ein erhoehtes Risiko gegenueber NTFS besteht nur bei instabilen
Systemen.
>Um eine Datei
>zuverl�ssig wiederherzustellen, muss man Wissen, dass sie nicht
>fragmentiert bzw. nicht von freien Clustern unterbrochen war.
Das muss man nicht wissen. Wenn sie es aber war, ist es ungemein
hilfreich und Chancen erhoehend.
>Kurzum, die Wiederhergestellten Daten sind
>nicht als zuverl�ssig oder unzuverl�ssig zu erkennen.
Doch, aber nicht mit den OS ueblichen Mitteln.