Diskussion:Sparse-Datei

aus Wikipedia, der freien Enzyklopädie

Die Artikel NTFS Sparse und Sparse-Datei behandeln das gleiche Thema. Vielleicht sollten diese Artikel zusammengeführt werden? --Noodels1977 10:22, 28. Feb 2006 (CET)

-Gesagt getan...--Noodels1977 17:19, 28. Feb 2006 (CET)

[Bearbeiten] Komplett mit Nullbytes überschreiben

Ich habe ein Problem mit dem Satz

"Es ist daher bei vielen Datenbanksystemen üblich, dass neu angelegte Dateien einmal komplett (mit Nullbytes) beschrieben werden, um so die Datenblöcke im Dateisystem vollständig zu belegen und so zu verhindern, dass die Datei übermäßig fragmentiert wird."

Ich weiß zufällig, dass die hier interpretierte Kausalitätskette nicht (so) vorhanden ist. Es gibt andere Gründe, es so zu machen (z.B. nicht alle Dateisysteme erlauben "overseeking", d.h. einen seek() über das Ende der Datei hinweg). Ich würde den Satz gerne streichen, habe aber das Gefühl, dass da mehr Weisheit verborgen sein mag, als ich derzeit erkenne. Bitte kommentieren...--Yanestra 05:52, 1. Mär 2006 (CET)

Meines Wissens nach gehen gewisse Programme tatsächlich so vor, wie beschrieben. Das ist also kein Widerspruch zu der Sache mit dem Overseeking, nur ein anderer Grund. Was ich nicht ganz verstehe ist hingegen die Sache mit der inhärenten Fragmentierung im Satz davor. Wenn zwischen zwei "echten Datenblöcken" 40 Cluster mit Nullbytes deklariert sind, kann das Dateisystem die doch ohne Zeitverlust zurückgeben. Die echten Datenblöcke können im Idealfall an einem Stück hintereinander stehen und die "Nullblöcke" kann das Dateisystem verzögerungsfrei generieren, sie müssen schließlich nicht von der Platte gelesen werden.--Harmonica 10:28, 1. Mär 2006 (CET)

Wenn ein Programm eine Datei beschreibt, belegt das Dateisystem für diese Datei nach und nach Datenblöcke. Die meisten Dateisysteme allokieren Datenblöcke linear, aus einer Liste der freien Blöcke. Die Datei liegt nach diesem Vorgang also zum größten Teil linear auf der Platte, also aufeinanderfolgende Blöcke der Datei liegen in aufeinanderfolgenden Blöcken der Platte (genauer: des Dateisystems), außer wenn zur gleichen Zeit noch eine andere Datei "wächst" und Blocke allokiert. Einige Dateisysteme reservieren aus Performancegründen beim Anlegen einer neuen Datei gleich mehrere Datenblöcke vor, bzw. beim Wachsen der Datei wird nicht nur 1 Block allokiert, sondern gleich die Darauffolgenden "vorreserviert", da man damit rechnet, dass die Datei weiter wachsen wird (Pre-allocate). Falls nun mehrere Dateien parallel geschrieben werden – was bei Multitasking-Multiuser-Systemen ja nicht so selten vorkommt – vermeidet das, dass die freien Blöcke immer abwechselnd je einer Datei zugeordnet werden, was die Performance beim anschließenden Lesen jeder dieser Dateien doch arg verschlechtern würde.

Ich kenne kein Dateisystem (von komprimierenden Dateisystemen mal abgesehen), welches beim Schreiben prüft, ob ein Datenblock mit Nullbytes geschrieben wird, und diesen von der Allokierung ausnimmt. Das würde einfach zu viel Performance kosten. Es ist also egal, was für Bytes man schreibt; das Schreiben bewirkt stets, dass das Dateisystem für diese Datei Datenblöcke allokieren muss. Wenn das Dateisystem nun also "pre-allocating" macht, oder das Programm gerade als einziges Daten schreibt und Blöcke allokiert, ist die Chance recht groß, dass für die Datei wirklich aufeinanderfolgende Datenblöcke belegt werden und so die Datei nicht fragmentiert ist und somit später flott gelesen werden kann.

Würde man dagegen eine Datei anlegen, dann 10 Mio. Dateiblöcke "vorspringen" und dort etwas schreiben, dann würde eine Datei angelegt, ggf. ein paar Blöcke "vorreserviert", aber dann folgen die Dateiblöcke ab 10 Mio. und diese belegen die darrauffolgenden Dateisystem-Blöcke. Springt man nun zu Dateiblock 2 Mio, werden dafür die darrauffolgenden Dateisystemblöcke genommen. Mit jedem weiteren Sprung wird die Datei somit weiter fragmentiert, sofern die Sprünge nicht in bereits reservierte oder vorreservierte Bereiche landen.

Nun verständlich? :-/ --RokerHRO 09:10, 12. Mär 2006 (CET)

[Bearbeiten] Beispiel

Ich hab edas Beispiel kommentiert. Dabei stellte sich mir die Frage, ob dd nicht zumindest ein Byte schreiben muss, was es ja durch count=0 eher nicht tut. Reicht das Seeken allein aus? -- 195.37.61.3 14:30, 20. Jun. 2007 (CEST)

[Bearbeiten] Belege

Ich vermisse einen Beleg für die Aussage "Durch eine fehlerhafte Implementierung werden Dateien nun immer in der vollen Größe auf dem Datenträger erstellt und nicht in der Größe, den die tatsächlichen Nutzdaten beanspruchen." Solch ein Satz sollte nicht ohne Quellenangabe geschrieben werden, da er so schnell zu Propaganda-Zwecken taugt. Von der EFS-Implementierung hat man auch behauptet, sie würde bei Windows 2000 fehlerhaft sein. Letztendlich behinderten jedoch nur US-amerikanische Gesetze Microsoft daran, eine stärkere Verschlüsselung zu verwenden. Ich will damit sagen, ist dies möglicherweise nicht falsch implementiert, sondern in irgendeiner Weise Absicht?

Ich habs erstmal auskommentiert. --RokerHRO 13:46, 20. Jan. 2008 (CET)