Diskussion:Sparse-Datei

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Sparse-Datei“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

NTFS Sparse vs. Sparse-Datei

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)

Dieser Abschnitt kann archiviert werden. arilou (Diskussion) 14:17, 28. Mär. 2013 (CET)

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)

Aufgrund einer Beleg-Anfrage (Edit) von Benutzer:Itu will ich versuchen, nochmals möglichst anschaulich auf das Problem "Fragmentierung" einzugehen. (Hm, vielleicht sollte auch der Artikel es etwas anschaulicher ausführen.)

1. Eine Anwendung erstellt eine Sparse-Datei mit z.B. 1000 KB (theoretischer) Länge, von denen die Bereiche 100..200 k und 500..600 k tatsächlich gefüllt sind. Warum macht sie das? Weil die restlichen Bereiche evtl. später noch befüllt werden, jetzt aber erst mal Platz sparen sollen.
2. Auf der Festplatte werden diese beiden jeweils 100 KB langen Blöche direkt aufeinanderfolgend gespeichert.
3. Später möchte die Anwendung in den Bereich 0..50 k Daten speichern. Diese 50 KB landen (bestenfalls) direkt hinter den bisherigen 2 Blöcken. Anschließend speichert die Anwendung in den Bereich 600..900 k, was (um auch mal 'nen anderen Fall zu haben) nicht mehr hinter die Datei passt und "sonstwo" auf der Platte einen Abschnitt erhält.

Man sieht: Schon von Anfang an ist der Adressbereich 200..500 k zwingend darauf festgelegt, dass ein Speichern dort zu Fragmentierung führt. Die meisten Dateisysteme lassen auch vor einer Datei keinen Freiplatz.
Alternativ:

1. Die Anwendung speichert erst mal 1000 KB Nullen (Adresse 0..1000 k) und sagt dem Dateisystem "ist 'ne normale Datei (kein Sparse)". Das Dateisystem, bemüht eine Fragmentierung zu vermeiden, findet eine groß genuge Lücke "am Stück".
2. Jedes weitere Speichern der Anwendung überschreibt nur den jew. Bereich, die Datei wird gar nicht fragmentiert.

Ich hoffe, mit diesem Beispiel geholfen zu haben. --arilou (Diskussion) 09:18, 3. Apr. 2013 (CEST)

PS: Ich finde es ausreichend anschaulich und logisch verständlich, dass dafür nicht auch noch ein Beleg aus der Literatur notwendig ist. --arilou (Diskussion) 09:09, 4. Apr. 2013 (CEST)

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)

Muss es nicht. Es ist schlicht Implementierungsabhängig. Unter SunOS5.10 wird beispielsweise count=0 anders interpretiert als unter GNU/Linux. Bei letzteren bewirkt ein count=0, dass weder Daten gelesen noch geschrieben werden, weshalb keine Quelle zwingend angegeben werden muss. Unter besagter SunOS-Version muss zumindest true |dd of=sparsefile bs=1 count=EGAL seek=10000 schreiben oder schlicht aus /dev/null lesen (was nix liefert)

-bash-3.00$ dd if=/dev/null of=sparsefile ibs=1 obs=1 count=0 seek=10000000000
0+0 records in
0+0 records out
-bash-3.00$ du -sh sparsefile 
  32K   sparsefile
-bash-3.00$ ls -lha sparsefile 
-rw-------   1 schily schily     9.3G Aug 23 17:53 sparsefile

Warum Schily glaubt, dass bei count=0 automatisch Posix-write() mit Daten der Länge 0 aufgerufen werden müsste, würde mich interessieren. Warum ein echo foo |dd of=sparsefile bs=1 count=0 seek=EGAL am Ende des Sparsefiles foo anfügt unter SunOS, kann ich mir jedoch nicht erklären. (nicht signierter Beitrag von 92.227.2.3 (Diskussion) 18:00, 23. Aug. 2010 (CEST))

Danke, daß Du nun selbst belegst, daß Deine Behauptungen zum Thema Linux nichts als Unsinn sind. Ein einacher seek auf eine Datei hat keinerlei Auswirkungen auf die Datei selbst. Bleiben wir doch einfach bei dem was im Standard steht und was experimentll bestätigt wurde. --Schily 19:12, 23. Aug. 2010 (CEST)

Ich habe mich nicht widerlegt, du liest nur selektiv. Ich habe NIRGENDS behauptet, dass ein seek auf einer Datei Auswirkungen hat. Ich habe lediglich behauptet, dass count=0 eben kein write() aufruft (Leicht zu finden in dd.c), wie du das behauptet hast. Dass nach dem seek *immer* ein truncate kommt (wenn man das dd mittels notrunc nicht verbietet) sollte sogar dir klar sein. 78.55.57.174 15:35, 25. Aug. 2010 (CEST)

Dieser Abschnitt kann archiviert werden. arilou (Diskussion) 14:17, 28. Mär. 2013 (CET)

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)

Dieser Abschnitt kann archiviert werden. arilou (Diskussion) 14:17, 28. Mär. 2013 (CET)

Binär oder SI Präfix?

Einmal ist die Rede davon, dass mit dem dd Befehle eine Datei mit der Größe von 10 GiB erzeigt wird, später wird eine Datei mit der Größe von 10 MB erzeugt. Hier wäre zu klären, ob dd Binär oder SI Präfixe verwendet.

--217.237.148.105 01:03, 7. Dez. 2009 (CET)

Das hängt ganz von der konkreten Implementierung ab. Die aktuellen dd-Versionen der GNU Coreutils beherrschen beides, anscheinend ist aber die Dokumentation widersprüchlich:

„bytes können folgende multiplikativen Endungen tragen: xM M, c 1, w 2, b 512, kD 1000, k 1024. MD 1.000.000, M 1.048.576, GD 1.000.000, G 1.073.741.824, und so weiter für T, P, E, Z, Y.“,

wohingegen die englische Doku das Suffis B statt D für die dezimalen(!) Vielfache will. Allerdings werden auch die IEC-Binärpräfixe explizit unterstützt:

„A bare size letter, or one followed by `iB', specifies a multiple using powers of 1024. A size letter followed by `B' specifies powers of 1000 instead. For example, `1M' and `1MiB' are equivalent to `1048576', whereas `1MB' is equivalent to `1000000'.“

Zudem berücksichtigt das Programm noch die Umgebungsvariable BLOCK_SIZE: Wenn diese den Wert "si" hat, dann ist 1 M = 1000000. Somit sollte man stets "1MD" oder "1MiB" nehmen, wenn man sicher sein will. :-(

Was den Artikel angeht: Bedanke dich bei denen, die hier in der Wikipedia für diesen Kuddelmuddel abgestimmt haben und es anderen verbieten wollen, unmissverständliche Einheitenpräfixe zu verwenden. --RokerHRO 08:32, 7. Dez. 2009 (CET)

Dieser Abschnitt kann archiviert werden. arilou (Diskussion) 14:17, 28. Mär. 2013 (CET)

wie jetzt?

Was sind denn die Bedingungen dass eine ausreichend nullhaltige Datei als platzsparende Sparse-Datei abgelegt wird? Dass man irgendwie speziell eine erzeugen kann ist erstmal sehr nutzlos. --in enWP steht das mit cp , das fehlt hier noch. --Itu (Diskussion) 05:53, 25. Mär. 2013 (CET)

Wenn ein Programm eine Datei von vorne bis hinten beschreibt, wird i.d.R. keine Sparse-Datei erzeugt, ganz egal, was für Daten da geschrieben werden. (wobei natürlich ein Dateisystem denkbar wäre, dass speziell für diesen Fall optimiert wäre, mir ist aber kein Dateisystem bekannt, das das tun würde.) "Löcher" in einer Datei entstehen nur, wenn das erzeugende Programm in der Datei (nach hinten) springt und dann weiter schreibt, und das Dateisystem Sparse-Dateien unterstützt. Aber genau das steht doch auch im Artikel. Oder etwa nicht? --RokerHRO (Diskussion) 07:38, 25. Mär. 2013 (CET)

Nicht wirklich. --Itu (Diskussion) 08:18, 25. Mär. 2013 (CET)

Ich war mal so frei, zumindest in Einleitung und Grundlagen diesbezüglich zu korrigieren. Wenn man den Artikel von oben nach unten liest, wird man jetzt langsam von "unbestimmten Bereichen" auf die "Nullbytes" geführt, so dass es in den unteren Abschnitten nicht mehr so weh tut. --arilou (Diskussion) 10:12, 25. Mär. 2013 (CET)

Wenn ich deinen 2 Edits jetzt folge dann würden allgemein unwichtige Bereiche(durch was auch immer bestimmt) als Nullreihe expandiert. So hatte ich das bisher nicht wahrgenommen. --Itu (Diskussion) 03:36, 26. Mär. 2013 (CET)

Mir ist nicht klar, was du mit "unwichtige Bereiche" und mit "Nullreihe" meinst. --RokerHRO (Diskussion) 21:25, 26. Mär. 2013 (CET)

i)Bereiche ohne Informationsgehalt allgemein, ii) aufeinanderfolgende Nullbytes. --Itu (Diskussion) 05:11, 27. Mär. 2013 (CET)

Naja, dass die Bereiche einer Datei, die beim Schreiben "übersprungen" wurden, beim anschließenden Lesen zu Nullbytes werden (und somit beim Lesen nicht erkennbar ist, ob da gerade „Löcher“ in der Datei ausgelesen werden, oder einfach nur Bllöcke, in die explizit Nullbytes geschrieben wurden), stand vorher schon drin. :-/ --RokerHRO (Diskussion) 07:48, 28. Mär. 2013 (CET)

Begrifflichkeit

Um das mal festzuhalten: Die Probleme fangen ganz vorne damit an dass mit dem Begriff Sparsedatei sowohl die komprimierbare als auch die komprimiert gespeicherte Datei bezeichnet werden. --Itu (Diskussion) 20:19, 1. Apr. 2013 (CEST)

Hab' mal das "kann" aus dem ersten Satz der Einleitung gekillt. Als "Sparsedatei" bezeichnet man nur jene, die "zusammengeschoben" auf der Festplatte liegt. --arilou (Diskussion) 14:12, 2. Apr. 2013 (CEST)

Sagst du! Gibt es überhaupt eine Quelle, die das begrifflich trennt? --Itu (Diskussion) 15:35, 2. Apr. 2013 (CEST)

PS: Was noch nicht auf die Festplatte geschrieben wurde, ist noch keine Datei... (--arilou (Diskussion) 14:13, 2. Apr. 2013 (CEST))

Mit dieser Definition stolperst du schon vorm loslaufen --Itu (Diskussion) 15:35, 2. Apr. 2013 (CEST)

Falls gewünscht, kann das "wird" im 1.Satz des Artikels auch durch ein "ist" ersetzt werden. --arilou (Diskussion) 14:15, 2. Apr. 2013 (CEST)

1. Bitte sachlich bleiben.

2. Bitte Artikel Datei, 1. Satz lesen. Als Datei bezeichnet man nur das, was auf einem Medium gespeichert ist. (Das darf auch eine Ramdisk sein.) Was davor an Daten existiert (im Ram der Anwendung), sind "Daten eines Anwendungsprogramms". Die gewünschte Quelle ist somit der WP-Artikel Datei (und dessen Quellen).

3. Da nur die abgespeicherte Version der Daten überhaupt eine "Datei" ist, gibt es auch keine Notwendigkeit, die Ram-Version der Daten "begrifflich [davon zu] trennen".

--arilou (Diskussion) 08:58, 3. Apr. 2013 (CEST)

Ich glaube ja an einen Interpretationsfehler

Zur Zeit gehe ich stark davon aus, dass eine Sparse-Datei eine Datei erzeugt, die auch auf dem Datenträger die volle Menge Sektoren belegt. Nur führt ein "seek(10000); write(...)" dazu, dass die Sektoren der Platte allokiert aber nicht beschrieben werden. Das spart Zeit beim Schreiben. In der Interpretationsweise, dass (wie die Illustration zeigt) die Daten auf weniger Speicher geschrieben werden, sehe ich keinen Vorteil: Der Speicher muss vorhanden sein, wenn man soviel allokieren will. Der "gesparte" Platz ist ja nicht wirklich zugänglich. Dann ist es gleich besser, den Speicher in Reihenfolge zu allokieren. Dann können normale HDDs sequenziell lesen, das ist schneller. Ich müsste aber noch in den Quellcode gucken, um das zu belegen. --2003:C7:1737:E9AC:846E:12CA:4F24:A212 11:57, 10. Feb. 2020 (CET)

Da scheint ein Verständnisfehler deinerseits vorzuliegen.

Es gibt Datenformate, bei denen bestimmte Informationen ganz am Ende der Datei stehen müssen. Auch wenn in den Daten davor große Bereiche (noch) nicht gefüllt sind. Solche Formate sind natürlich gerade dann kein Unsinn, wenn es auf dem OS Sparse-Dateien im Sinne hiesigen Artikels gibt.

In welchen "Quellcode" du sehen willst, um eine Aussage für ALLE Betriebssysteme treffen zu können, ist mir ebenfalls schleierhaft. Apples OS X, Linux, Solaris, Windows, ...

--arilou (Diskussion) 13:10, 10. Feb. 2020 (CET)