SFS — Änderungen 8409 → 8410

Zeile 1:

−

{{~~Warnung~~|Text=Achtung, alles was hier steht ist von extrem eingeschränkter Nützlichkeit und man sollte sich gut überlegen ob man das wirklich implementieren will!<br />Selbst das simple FAT ist dem SFS um Längen überlegen, u.a. weil SFS keine fragmentierten Dateien unterstützt und sich daher echter Schreibzugriff nur äußerst schwer und langsam implementieren lässt!}}

{{Achtung|Text=Achtung, alles was hier steht ist von extrem eingeschränkter Nützlichkeit und man sollte sich gut überlegen ob man das wirklich implementieren will!<br />Selbst das simple FAT ist dem SFS um Längen überlegen, u.a. weil SFS keine fragmentierten Dateien unterstützt und sich daher echter Schreibzugriff nur äußerst schwer und langsam implementieren lässt!<br />Siehe dazu auf die [[Diskussion:SFS|Diskussionsseite]] und in den Abschnitt [[SFS#Vergleich%20mit%20anderen%20Dateisystemen|Vergleich mit anderen Dateisystemen]]}}

Zeile 7:

Vorteile des SFS:

*Einfacher Aufbau

**Wobei [[FAT]] auch nur dann wirklich komplizierter ist wenn man lange Dateinamen unterstützen möchte

Nachteile des SFS:

−

*Keine native Unterstützung unter Linux oder ~~Windows~~

*Keine native Unterstützung unter Linux, Windows oder anderen relevanten Betriebssystemen

**Unter Windows existiert ein unvollständiges Tool, um auf SFS-Images zuzugreifen

*Dateien müssen zusammenhängend sein, d.h. Schreibzugriff erfordert aufwändige und langsame Online-Defragmentierung

*Die Defragmentierung kann nicht sicher implementiert werden (d.h. ein Absturz/Stromausfall während der Defragmentierung zieht zwangsläufig Datenverlust oder -korruption nach sich)

*Flash-basierte Datenträger (USB-Sticks oder SSDs) könnten aufgrund des häufigen Defragmentierens schneller altern.

==Aufbau==

Zeile 37:

Zeile 39:

Für die Implementierung einer Schreibunterstützung sind bereits einige grundlegende Operationen nötig, die mit SFS sehr mühsam und nur unsicher (Gefahr von Datenverlust und Korruption!) zu erreichen sind, z.B. das Erstellen, Vergrößern oder Verkleinern von Dateien.

−

Auch ansonsten bietet SFS gegenüber anderen ähnlich simplen Dateisystemen, wie z.B. [[FAT]], keine Vorteile. FAT kann recht flexibel mit fragmentierten Dateien umgehen und erlaubt daher einigermaßen simple Schreiboperationen. Dafür hat FAT mit seiner namensgebenden File-Alocation-Table gegenüber SFS einen etwas komplexeren Mechanismus, mit dem die Positionen der Datenblöcke auf dem Datenträger verwaltet werden. Man ist bei FAT selbst schon für das lineare Einlesen von Dateien gezwungen, einer Cluster-Kette zu folgen (was aber auch nicht so schwierig ist, zumindest einfach genug damit man das in einem FAT-Boot-Sektor realisieren kann).

==Weblinks==

@@ Zeile 1: / Zeile 1: @@
-{{Warnung|Text=Achtung, alles was hier steht ist von extrem eingeschränkter Nützlichkeit und man sollte sich gut überlegen ob man das wirklich implementieren will!<br />Selbst das simple FAT ist dem SFS um Längen überlegen, u.a. weil SFS keine fragmentierten Dateien unterstützt und sich daher echter Schreibzugriff nur äußerst schwer und langsam implementieren lässt!}}
+{{Achtung|Text=Achtung, alles was hier steht ist von extrem eingeschränkter Nützlichkeit und man sollte sich gut überlegen ob man das wirklich implementieren will!<br />Selbst das simple FAT ist dem SFS um Längen überlegen, u.a. weil SFS keine fragmentierten Dateien unterstützt und sich daher echter Schreibzugriff nur äußerst schwer und langsam implementieren lässt!<br />Siehe dazu auf die [[Diskussion:SFS|Diskussionsseite]] und in den Abschnitt [[SFS#Vergleich%20mit%20anderen%20Dateisystemen|Vergleich mit anderen Dateisystemen]]}}
@@ Zeile 7: / Zeile 7: @@
 Vorteile des SFS:
 *Einfacher Aufbau
+**Wobei [[FAT]] auch nur dann wirklich komplizierter ist wenn man lange Dateinamen unterstützen möchte
 Nachteile des SFS:
-*Keine native Unterstützung unter Linux oder Windows
+*Keine native Unterstützung unter Linux, Windows oder anderen relevanten Betriebssystemen
 **Unter Windows existiert ein unvollständiges Tool, um auf SFS-Images zuzugreifen
 *Dateien müssen zusammenhängend sein, d.h. Schreibzugriff erfordert aufwändige und langsame Online-Defragmentierung
 *Die Defragmentierung kann nicht sicher implementiert werden (d.h. ein Absturz/Stromausfall während der Defragmentierung zieht zwangsläufig Datenverlust oder -korruption nach sich)
+*Flash-basierte Datenträger (USB-Sticks oder SSDs) könnten aufgrund des häufigen Defragmentierens schneller altern.
 ==Aufbau==
@@ Zeile 37: / Zeile 39: @@
 Für die Implementierung einer Schreibunterstützung sind bereits einige grundlegende Operationen nötig, die mit SFS sehr mühsam und nur unsicher (Gefahr von Datenverlust und Korruption!) zu erreichen sind, z.B. das Erstellen, Vergrößern oder Verkleinern von Dateien.
-Auch ansonsten bietet SFS gegenüber anderen ähnlich simplen Dateisystemen, wie z.B. [[FAT]], keine Vorteile. FAT kann recht flexibel mit fragmentierten Dateien umgehen und erlaubt daher einigermaßen simple Schreiboperationen. Dafür hat FAT mit seiner namensgebenden File-Alocation-Table gegenüber SFS einen etwas komplexeren Mechanismus, mit dem die Positionen der Datenblöcke auf dem Datenträger verwaltet werden. Man ist bei FAT selbst schon für das lineare Einlesen von Dateien gezwungen, einer Cluster-Kette zu folgen (was aber auch nicht so schwierig ist, zumindest einfach genug damit man das in einem FAT-Boot-Sektor realisieren kann).
+Auch ansonsten bietet SFS gegenüber anderen ähnlich simplen Dateisystemen, wie z.B. [[FAT]], keine Vorteile. FAT kann recht flexibel mit fragmentierten Dateien umgehen und erlaubt daher einigermaßen simple Schreiboperationen. Dafür hat FAT mit seiner namensgebenden File-Alocation-Table gegenüber SFS einen etwas komplexeren Mechanismus, mit dem die Positionen der Datenblöcke auf dem Datenträger verwaltet werden. Man ist bei FAT selbst schon für das lineare Einlesen von Dateien gezwungen, einer Cluster-Kette zu folgen (was aber auch nicht so schwierig ist, zumindest einfach genug damit man das in einem 512 Byte-FAT-Boot-Sektor realisieren kann).
 ==Weblinks==