staging.inyokaproject.org

kaputtnik schrieb:

Ein Medium muss aber explizit mit einem Dateisystem formatiert werden. Das spricht doch dafür, das es Hardwareabhängig ist.

Nein, ein Medium muß nicht explizit mit einem Dateisystem formatiert werden: Ich kann z.b. den Inhalt einer Datei mit "dd" direkt auf die Platte schreiben (Dazu müßte die Platte nicht einmal Partitionen haben). Nun stelle ich folgende Überlegung an: "Hmm, die Datei ist 1000 Byte groß. Wunderbar, dann kann ich ab Position 1024 ja meine zweite Datei mit dd reinschreiben und hätte in der ersten Datei ja sogar noch wunderbar Platz für 24 weitere Zeichen." Genau das sind die Dinge, um die sich das Dateisystem kümmert. Natürlich ist das Thema viel (!) komplizierter.

Ein zweiter "Beweis", dass das Dateisstem nicht hardwareabhängig ist: Richte eine Virtuelle Maschine ein, mit einer virtuellen Festplatte. Diese Festplatte ist in Wirklichkeit nur eine große Datei. Und dennoch kannst Du in der VM auf der virtuellen Platte ein Dateisystem anlegen.

Ich stoße mich halt immer an dem Begriff "Datenorganisation", welcher für mich eher einer (selbsterstellten oder vom BS vorgegebenen) Verzeichnisstruktur entspricht.

Das Dateisystem stellt die Möglichkeit einer Strukturierung mittles Verzeichnissen zur Verfügung. Da tatsächlichen Daten werden auf der Platte dabei bei weitem nicht so schön strukturiert abgelegt. Da herscht ein großes Durcheinander. (z.b. Fragmentierung, Reihenfolge). Oder: Dateien, die z.b. innerhalb eines Verzeichnisses "direkt" hintereinander liegen, können auf der Platte an völlig unterschiedlichen Orten liegen.
"Verzeichnisstruktur" ist die Art und Weise, wie diese Möglichkeit vom Betriebsystem genutzt wird.
Das Dateisystem stellt ganz abstrakt die Möglichkeit zur Verfügung, Verzeichnisse und Unterverzeichnisse anzulegen, also z.b.

/
/A
/A/B
/A/B/C

Das Dateisystem weiß aber nichts von der "semantischen" Bedeutung dieser Verzeichnisse. /A/B/C könnte genauso gut /usr/local/bin heißen. Das ist dem Dateisystem egal. Nicht aber dem Betriebsystem. Dies legt eben eine _bestimmte_ Verzeichnisstruktur fest und definiert, dass es nicht /A/B/B sonder /usr/local/bin heißen muss. Das ist die bestimmte Verzeichnisstruktur eines Gnu/Linux-Systems.

Jup, der Dateisystemtreiber gehört mit rein.

Nö, eigentlich nicht, da er mit dem Dateisystem nichts zu tun hat 😉 Aber ja er gehört rein, da ein Artikel ruhig etwas über den Tellerrand blicken sollte, damit man das eigentlich beschriebene Thema besser im Gesamtbild einordnen kann.

Ich möchte gerne den Unterschied klar machen, zwischen "Datenorganisation im Sinne von Verzeichnisstruktur" und "Datenorganisation im Sinne von Dateisystem". Wie schreiben?

Vielleicht so, wie ich es oben versucht habe? Die Verzeichnisstruktur beschreibt die Bedeutung bestimmter Verzeichnisse. Wie die Verzeichnisse hinter den Kulissen umgesetzt sind, ist für die Verzeichnisstruktur völlig irrelevant.

Ok, ok... is ja gut 😉

Also was haben wir:

1. Das Dateisystem bietet einem Bs oder dem Nutzer u.a. die Möglichkeit

   • Verzeichnisse anzulegen, ein Verzeichnisstruktur zu schaffen

   • Lange Dateinamen zu benutzen

   • Groß- und Kleinschreibung zu berücksichtigen

   • Sonderzeichen für Namen zu gebrauchen (zB Leerzeichen)

   • Dateien/Verzeichnisse mit einem Rechtesystem zu reglementieren

   • Journaling- funktionen

   • ...

2. Die Formatierung einer Partition bewirkt

   • Überprüfung auf fehlerhafte Sektoren

   • ... ja und hier hakts wieder... Auch wenn man mit dd direkt auf die Platte schreiben kann (swap wäre auch ein Beispiel für eine nicht explizit formatierte Partition), so muss für eine "normale" Nutzung einer Partition (Auch Diskette und CD) diese mit einem Dateisystem formatiert werden. Wo ist der zusammenhang zwischen Formatierung und Dateisystem? In den zuvor genannten Links wird immer davon gesprochen, das etwas auf der Platte verändert wird:

"Das wesentliche am formatieren ist das die magnetische Oberfläche des Datenträgers in eine bestimmte Anzahl Spuren den sogenannten Tracks und Sektoren pro Spur eingeteilt wird." (Quelle)

"Beim Formatieren (im Linux-Sprachgebrauch auch als "Erstellen eines Dateisystems" bezeichnet) werden Informationen auf die Festplatte geschrieben, die Ordnung in den leeren Speicherplatz einer unformatierten Festplatte bringen." (Quelle)

Formatierung und Dateisystem gehören zusammen, denn man formatiert ja "mit" einem Dateisystem.

Vllt ist es doch besser, wenn jemand anderes den Artikel überarbeitet. Die Diskussion ist zwar interessant und lehrreich, aber ich habe das Gefühl auf der Stelle zu treten bzw nicht genug Abstrakationsvermögen zu haben...

Jetzt bloß nicht aufgeben! 😉

kaputtnik schrieb:

Also was haben wir:

1. Das Dateisystem bietet einem Bs oder dem Nutzer u.a. die Möglichkeit

   • Verzeichnisse anzulegen, ein Verzeichnisstruktur zu schaffen

   • Lange Dateinamen zu benutzen

   • Groß- und Kleinschreibung zu berücksichtigen

   • Sonderzeichen für Namen zu gebrauchen (zB Leerzeichen)

   • Dateien/Verzeichnisse mit einem Rechtesystem zu reglementieren

   • Journaling- funktionen

Diese Liste beschreibt schon ein sehr bestimmtes Dateisystem. Ich würde die Punkte so formulieren, dass sie die Entscheidung noch nicht treffen, also z.b.: "Das Dateisystem legt fest, ob lange Dateinamen benutzt werden können, ob Groß-/Kleinschreibung ...". Schließlich gibt es auch Dateisysteme, die hier erhebliche Unterschiede aufweisen. Ich vermute das nur die POSIX-kompatiblen Dateisystem starke Übereinstimmungen aufzeigen.

• ...

1. Die Formatierung einer Partition bewirkt

... ganz einfach nur, dass auf der Platte/Partition einfach ein frisches leeres Dateisystem angelegt wird. Als Beispiel: Auch ein leeres Heft ist bereits in Seiten eingeteilt... Aber vorsicht: Vergleiche hinken...

• Überprüfung auf fehlerhafte Sektoren

Das ist nicht die Aufgabe der Formatierung. Allerdings bieten die meisten Programme zur Formatierung (z.b. mkfs.ext3) dazu Optionen.

• ... ja und hier hakts wieder... Auch wenn man mit dd direkt auf die Platte schreiben kann (swap wäre auch ein Beispiel für eine nicht explizit formatierte Partition), so muss für eine "normale" Nutzung einer Partition (Auch Diskette und CD) diese mit einem Dateisystem formatiert werden. Wo ist der zusammenhang zwischen Formatierung und Dateisystem?

Die Formatierung ist die Erschaffung eines leeren Dateisystems. Ganz einfach 😉

In den zuvor genannten Links wird immer davon gesprochen, das etwas auf der Platte verändert wird:

"Das wesentliche am formatieren ist das die magnetische Oberfläche des Datenträgers in eine bestimmte Anzahl Spuren den sogenannten Tracks und Sektoren pro Spur eingeteilt wird." (Quelle)

Hier mag die hardwareseitige Formatierung gemeint sein. Formatierung kann ja auf verschiedenen Ebene existieren. Beispiel: Es existiert ein Dateisystem (welches ein "Format" hat). In diesem Dateisystem legst Du eine Datei an dessen Inhalt Du nach deinem Wünschen formatiern kannst. z.b. Eine Telefonnummer pro Zeile. Oder Komma-separiert. Oder beides... Vielleicht legt dein Format auch fest, dass ganz am Anfang die Anzahl der existierenden Telefonnummern steht. Das sähe dann so aus:

2
4711-1234
0815-9933

Frisch formatiert sähe die Datei so aus:

0

, aber eben nicht

. Es ist eben eine Frage der Definition.
Und in der anderen Richtung (Richtung Hardware) mag eine sonstwie geartete Formatierung der Platte existieren, die möglicherweise nur die Hardware selbst kennt, z.b. das BIOS. Die Einteilung in Sektoren usw. hat mMn aber nichts mit der Dateisystem-Formatierung zu tun. Lustig: Man kann soger innerhalb einer normalen Datei ganz einfach ein Dateisystem mit z.B. mkfs.ext3 anlegen 😉 Daran kannst Du gut verstehen, was formatieren ist. Mach mal folgendes:

dd if=/dev/zero of=platte bs=1M count=128

Das legt eine 128MiB große Datei an, die komplett mit "Null-Bytes" bzw Bits gefüllt ist. Prüfen kannst Du das mit

hexdump platte

(Der Stern in der Ausgabe kennzeichnet einen Bereich, in dem es zur vorangegangenen Zeile keinen Unterschied gibt.) Nun kannst Du mit

mkfs.ext3 platte

ein Dateisystem in der Datei anlegen. Du brauchst dazu keine Rootrechte, da die Datei ja Dir gehört. Gerade hast Du die Datei mit ext3 formatiert. Ein wiederholtes

hexdump platte

wird erstaunliches zu Tage fördern 😉 Natürlich kannst Du diese Datei auch mounten und dann ganz normal benutzen:

sudo mount -o loop platte /mnt

"Beim Formatieren (im Linux-Sprachgebrauch auch als "Erstellen eines Dateisystems" bezeichnet) werden Informationen auf die Festplatte geschrieben, die Ordnung in den leeren Speicherplatz einer unformatierten Festplatte bringen." (Quelle)

Genau, ein leeres Dateisystem wird angelegt. Das, was dir hexdump nach dem Formatieren anzeigt. (Interessant ist auch, die "Festplattendatei" zu mounten, dann eine Datei dort anzulegen, wieder unmounten und anschließend nach der Datei mittels hexdump zu suchen...)

Formatierung und Dateisystem gehören zusammen, denn man formatiert ja "mit" einem Dateisystem.

Korrekt. Formatierung ist die Anlage eines leeren Dateisystems.

Vllt ist es doch besser, wenn jemand anderes den Artikel überarbeitet. Die Diskussion ist zwar interessant und lehrreich, aber ich habe das Gefühl auf der Stelle zu treten bzw nicht genug Abstrakationsvermögen zu haben...

Es hat aber auch einen bestechenden Vorteil, wenn es jemand macht, der sich noch nicht so gut auskennt: Er ist näher an der späteren Zielgruppe des Wikiartikels 😉 Also: Nur Mut und durchhalten! 😉

DrScott schrieb:

Jetzt bloß nicht aufgeben! 😉

😊 😕

Diese Liste beschreibt schon ein sehr bestimmtes Dateisystem. Ich würde die Punkte so formulieren, dass sie die Entscheidung noch nicht treffen, also z.b.: "Das Dateisystem legt fest, ob lange Dateinamen benutzt werden können, ob Groß-/Kleinschreibung ...".

Desewgen hatte ich ja "Möglichkleit" geschrieben... aber gut, ist vllt nicht eindeutig genug. Neuer Voschlag

1. Ein Dateisystem kann einem Betriebssystem oder dem Nutzer u.a. folgende Möglichkeiten bieten:

   • Verzeichnisse anzulegen, ein Verzeichnisstruktur zu schaffen

   • ...

• ...

1. Die Formatierung einer Partition bewirkt

   • Überprüfung auf fehlerhafte Sektoren

Das ist nicht die Aufgabe der Formatierung. Allerdings bieten die meisten Programme zur Formatierung (z.b. mkfs.ext3) dazu Optionen.

Ich hatte gelesen, das diese Überprüfung der Grund dafür ist, das das Formatieren so lange dauert. Kann natürlich sein, das WinFormat das standardmäßig macht (außer bei Quickformat). mkfs macht das nur mit dem Optionsschalter -c und ohne Schalter geht das dann auch so schnell...

Und in der anderen Richtung (Richtung Hardware) mag eine sonstwie geartete Formatierung der Platte existieren, die möglicherweise nur die Hardware selbst kennt, z.b. das BIOS. Die Einteilung in Sektoren usw. hat mMn aber nichts mit der Dateisystem-Formatierung zu tun.

Komisch, Dein Beispiel sagt genau das Gegenteil... denn nach Formatierung mittels

mkfs.ext3 platte

sagt die Aussage, das etwas auf "platte" (gelungener Name 😉 ) geschrieben wurde:

Superblock-Sicherungskopien gespeichert in den Blöcken:
        8193, 24577, 40961, 57345, 73729

Schreibe Inode-Tabellen: erledigt
Erstelle Journal (4096 Blöcke): erledigt
Schreibe Superblöcke und Dateisystem-Accountinginformationen: erledigt

Und die anschließende Betrachtung mit

hexdump platte

bringt tatsächlich erstaunliches zu Tage 😉 (Das mit der Datei anlegen probiere ich später mal aus..). Auf jeden Fall wird die PLatte in irgendeiner Art eingeteilt. Und das betrifft nun wirklich die Hardware. Es werden zwar keine Sektoren, Zylinder und Spuren erstellt, (was meiner Meinung nach durch die Geometrie der Festplatte an sich festgelegt ist), aber es wird zB die Blockgröße und Anzahl festgelegt. Hmmm... gab es nicht auch mal Dateisysteme mit variabler Blockgröße?

OK, könnte man diesen Vergleich ziehen: Die Seiten eines Heftes sind leer, das Formatieren mit einem bestimmten Dateisystem malt entweder Karos oder Linien oder Rauten auf die Seiten (sozusagen Hilfslinien)? Ausserdem wird eine Art leeres Inhaltsverzeichnis für das Heft erstellt?
Was der User oder ein BS dann in das Heft schreiben will (Texte/Dateien), oder ob er eine Überschriften (Verzeichnisse) erstellen möchte, wird dem Dateisystem durch das BS mitgeteilt:

Das BS sagt zB: "Hallo Heft! Ich habe hier den User x, der möchte eine Überschrift mit Namen y haben, leg das mal an." Und das Heft guckt dann im Inhaltsverzeichnis nach, sieht das auf Seite 23 ab Zeile 6 und Spalte 7 (Karos sind praktisch 😉 ) noch Platz ist und schreibt dann die Überschrift y da rein. Gleichzeitig wird im Inhaltsverzeichnis vermerkt: Auf Seite 23, Zeile 6, Spalte 7 steht "y", ist eine Überschrift und ist z Bytes/Blöcke lang.

Du siehst, ich gebe mich nicht damit zufrieden, das ein Dateisystem "nur" eine Art Verzeichnis ist... Da gehört IMHO noch mehr dazu.

kaputtnik schrieb:

Komisch, Dein Beispiel sagt genau das Gegenteil... denn nach Formatierung mittels

mkfs.ext3 platte

sagt die Aussage, das etwas auf "platte" (gelungener Name 😉 ) geschrieben wurde:

Da habe ich mich wohl missverständlich ausgedrückt: Mit der Formulierung

Und in der anderen Richtung (Richtung Hardware) mag eine sonstwie geartete Formatierung der Platte existieren, die möglicherweise nur die Hardware selbst kennt,

wollte ich zum Ausdruck bringen, dass neben der Dateisystemformatierung durchaus noch weitere Formatierungen existieren können: In der einen Richtung z.b. Formatierungen innerhalb von Dateien, in der anderen Richtung Formatierungen, die nur von der Festplattensteuerung verstanden/benötigt werden (Einteilung in Sektoren, Cylinder und Leseköpfe). Einem Dateisystem ist völlig egal, wieviel Köpfe eine Platte hat. Es gibt Formatierungen auf unterschiedlichen Ebenen, die eben oft verwechselt/vermischt werden.

Und die anschließende Betrachtung mit

hexdump platte

bringt tatsächlich erstaunliches zu Tage 😉 (Das mit der Datei anlegen probiere ich später mal aus..). Auf jeden Fall wird die PLatte in irgendeiner Art eingeteilt. Und das betrifft nun wirklich die Hardware. Es werden zwar keine Sektoren, Zylinder und Spuren erstellt, (was meiner Meinung nach durch die Geometrie der Festplatte an sich festgelegt ist), aber es wird zB die Blockgröße und Anzahl festgelegt.

Das ist alles richtig. Ich versuche ja nur zu verdeutlichen, dass das Dateisystem und dessen Format unabhängig von der Hardware ist. Das Dateisystem erwartet von der Hardware nur folgende Eigenschaft: Konstante Adressierbarkeit der Bits. Wie die Hardware selbst diese Bits verwaltet ist dem Dateisystem egal. Mal ein Beispiel: Das Dateisystem legt ab Adresse 4711 genau 815 Bytes ab. Es erwartet, diese Bytes genau dort auch wieder lesen zu können. Die Blockgröße die Du angesprochen hast ist ein Teil des Dateisystemformats. Das hat nichts mit der Hardware zu tun.

OK, könnte man diesen Vergleich ziehen: Die Seiten eines Heftes sind leer, das Formatieren mit einem bestimmten Dateisystem malt entweder Karos oder Linien oder Rauten auf die Seiten (sozusagen Hilfslinien)? Ausserdem wird eine Art leeres Inhaltsverzeichnis für das Heft erstellt?
Was der User oder ein BS dann in das Heft schreiben will (Texte/Dateien), oder ob er eine Überschriften (Verzeichnisse) erstellen möchte, wird dem Dateisystem durch das BS mitgeteilt:

Das BS sagt zB: "Hallo Heft! Ich habe hier den User x, der möchte eine Überschrift mit Namen y haben, leg das mal an." Und das Heft guckt dann im Inhaltsverzeichnis nach, sieht das auf Seite 23 ab Zeile 6 und Spalte 7 (Karos sind praktisch 😉 ) noch Platz ist und schreibt dann die Überschrift y da rein. Gleichzeitig wird im Inhaltsverzeichnis vermerkt: Auf Seite 23, Zeile 6, Spalte 7 steht "y", ist eine Überschrift und ist z Bytes/Blöcke lang.

Du siehst, ich gebe mich nicht damit zufrieden, das ein Dateisystem "nur" eine Art Verzeichnis ist... Da gehört IMHO noch mehr dazu.

Sicher gehört mehr dazu. Rechte, Attribute, Zeitstempel...

Zu deinem Vergleich: So ganz passt das noch nicht: Im ersten Schritt wird im Heft ein Dateisystem angelegt, später sagst Du dann, das Heft (nicht das Dateisystem) würde irgendwo nachgucken. Ne ne, da ist etwas durcheinander 😉

Aber jetzt versuch ich's mal: Unsere Platte: ein leeres, aber kariertes Blatt Papier (Ob das große leere Blatt Papier in Wirklichkeit aus mehreren kleinen zusammengelegten Papierchen besteht, ist gar nicht erkennbar). Es ist nun möglich, jedes Karo genau anzusteuern, zu beschreiben und zu lesen. Das könnten wir z.b. mit "dd" machen.

Jetzt wird auf dem karierten Blatt ein leeres Dateisystem angelegt: Man muß ja davon ausgehen, dass das Blatt vielleicht doch gar nicht so weiß war. Es muß also sichergestellt werden, dass z.b. in dem Bereich, in dem später das Inhaltsverzeichnis liegt, kein alter Datenmüll liegt. Würde z.b. in dem Karo, welches die Anzahl der Unterverzeichnisse des "Stammverzeichnisses" wiedergibt, von vorneherein eine zufälliger Wert != 0 stehen, dann würde von Anfang an etwas schief laufen. Das Beispiel soll verdeutlichen, dass bestimmte Bereiche von vorne herein mit definierten Werten belegt sein müssen, damit das Dateisystem korrekt initialisiert ist. Da wäre z.b. der Superblock. der schon eine Menge an Informationen über das Dateisystem enthält (UUID, wann wurde es erstellt, unter welchem OS, Anzahl freier Datenstrukturen,...). Das dieser Superblock aus Gründen der Redundanz gleich mehrfach an verschiedene Stellen im gesamten Bereich des Dateisystems gespeichert ist, ist ein Grund, weshalb ein frisch formatiertes Dateisystem - direkt betrachtet - nicht erstmal komplett leer (nur Nullbytes) ist, sondern immer wieder Werte ausweist. Das sind die Werte, die Du per hexdump sehen konntest. Hättest Du beim Anlegen der "Platte" z.b. nicht /dev/zero verwendet, sondern /dev/urandom, dann wäre Dir aufgefallen, dass auch nach dem Formatieren der Partition weite Teile der Platte immer noch "random" sind. Das Formatieren initialisiert nur Bereiche, für die das erforderlich ist. Das Formatieren belegt bestimmte Bereiche als mit definierten Werten. Dabei sind Supberblock+Kopiene und Tabellen, die später die Informationen aufnehmen, welche Datei welche Blöcke belegt.

Wenn nun eine Datei gespeichert werden soll, dann speichert das Dateisystemprogramm einerseits natürlich den Inhalt der Datei, andererseits aber auch den Ort der Speicherung und die Attribute. Oft kann die Datei gar nicht "am Stück" geschrieben werden, da kein ausreichend großer Platz gefunden werden konnte, dann gibt es nicht den Ort, sondern die Orte. Beim Lesen der Datei führt das Dateisystem dann von Ort zu Ort.

DrScott schrieb:

kaputtnik schrieb:

bringt tatsächlich erstaunliches zu Tage 😉 (Das mit der Datei anlegen probiere ich später mal aus..). Auf jeden Fall wird die PLatte in irgendeiner Art eingeteilt. Und das betrifft nun wirklich die Hardware. Es werden zwar keine Sektoren, Zylinder und Spuren erstellt, (was meiner Meinung nach durch die Geometrie der Festplatte an sich festgelegt ist), aber es wird zB die Blockgröße und Anzahl festgelegt.

Das ist alles richtig. Ich versuche ja nur zu verdeutlichen, dass das Dateisystem und dessen Format unabhängig von der Hardware ist. Das Dateisystem erwartet von der Hardware nur folgende Eigenschaft: Konstante Adressierbarkeit der Bits. Wie die Hardware selbst diese Bits verwaltet ist dem Dateisystem egal. Mal ein Beispiel: Das Dateisystem legt ab Adresse 4711 genau 815 Bytes ab. Es erwartet, diese Bytes genau dort auch wieder lesen zu können. Die Blockgröße die Du angesprochen hast ist ein Teil des Dateisystemformats. Das hat nichts mit der Hardware zu tun.

OK. Also ist die Blockgröße nur eine Art Hilfsmittel zur Datenverwaltung. Die Blöcke werden nicht explizit auf die Platte geschrieben. sondern dienen einem Dateisystem nur dazu, ein gewisse Struktur einzuhalten.

So wie ich das jetzt verstehe, ist ein Dateisystem dann "nur" eine Art Datenverwaltungsprogramm, welches sich aber nicht um die direkte Speicherung der Daten kümmert. Es ist nur eine Schnittstelle zwischen User/BS und Datenträger. hmmm... Den Gedanken hattest Du schon mal moniert...

Ein Dateisystem teilt den Datenträger nicht in Blöcke ein, sondern die Daten. Dann wird nachgeguckt wo noch Platz für die Datenblöcke ist. Der Hardware wird dann gesagt: "Speicher mal diese Daten an Position soundso und soundso". Wird ein Block nicht ganz mit den Daten ausgefüllt, wird der Platz des Blocks aber vom Dateisystem als belegt "notiert", so daß die nächsten Daten erst wieder am anschließenden freien Block geschrieben werden. Die Festplatte selber weiß nichts von der Blockgröße, sie speichert die Daten nur an den Positionen die das Dateisystem vorgibt.

Formatierung:
Die Formatierung bewirkt, daß bestimmte Stellen auf dem Datenträger für die Verwaltung "reserviert" werden. Diese Stellen werden mit "0" überschrieben (was zu Datenverlust führt). Außerdem wird eine Art Inhaltsverzeichnis angelegt.

Fragen:

• Wo werden eigentlich die Attribute "archiv", "geändert", usw., von Dateien gespeichert? In den Dateien oder in der Inhaltstabelle?

• Wie kann man sich diese Attribute anzeigen lassen? "lsattr" bringt bei mir keine Infos:

~/Dokumente/Wiki Arbeiten/Dateisystem$ lsattr Texte.txt
------------------ Texte.txt

"Texte" wurde kurz vorher geändert und gespeichert.

kaputtnik schrieb:

OK. Also ist die Blockgröße nur eine Art Hilfsmittel zur Datenverwaltung. Die Blöcke werden nicht explizit auf die Platte geschrieben. sondern dienen einem Dateisystem nur dazu, ein gewisse Struktur einzuhalten.

Genau.

So wie ich das jetzt verstehe, ist ein Dateisystem dann "nur" eine Art Datenverwaltungsprogramm, welches sich aber nicht um die direkte Speicherung der Daten kümmert. Es ist nur eine Schnittstelle zwischen User/BS und Datenträger. hmmm... Den Gedanken hattest Du schon mal moniert...

Hatte ich? Ich finde diesen Satz von Dir sehr treffend. Das Dateisystem ist ein Programm, das denn gesamten Speicher eines Datenträgers vernünftig nutzbar macht. (Direkt und "unvernünftig" ist das ja schon mit "dd" möglich). Richtig: ein Dateisystem(programm) hat sehr viele Gemeinsamkeiten mit einer Datenbanksoftware.

Ein Dateisystem teilt den Datenträger nicht in Blöcke ein, sondern die Daten. Dann wird nachgeguckt wo noch Platz für die Datenblöcke ist. Der Hardware wird dann gesagt: "Speicher mal diese Daten an Position soundso und soundso". Wird ein Block nicht ganz mit den Daten ausgefüllt, wird der Platz des Blocks aber vom Dateisystem als belegt "notiert", so daß die nächsten Daten erst wieder am anschließenden freien Block geschrieben werden. Die Festplatte selber weiß nichts von der Blockgröße, sie speichert die Daten nur an den Positionen die das Dateisystem vorgibt.

Du hast heimlich irgendwo nachgelesen, oder? 😉 So ist es!

Formatierung:
Die Formatierung bewirkt, daß bestimmte Stellen auf dem Datenträger für die Verwaltung "reserviert" werden. Diese Stellen werden mit "0" überschrieben (was zu Datenverlust führt). Außerdem wird eine Art Inhaltsverzeichnis angelegt.

So ist es. Nur dass nicht unbedingt "0" verwendet wird. Richtig ist aber, dass bestimmte Stellen überschrieben werden, da diese Stellen für das Dateisystem bereits ab "Grundzustand" eine Bedeutung haben.

Fragen:

• Wo werden eigentlich die Attribute "archiv", "geändert", usw., von Dateien gespeichert? In den Dateien oder in der Inhaltstabelle?

In der Datei sicher nicht, denn das würde ja den Dateiinhalt verändern. Das wäre ein schlechtes Dateisystem. Wo dies tatsächlich gespeichert ist, könnte durchaus schon abhängig vom entsprechenden Dateisystem sein, aber deine Idee "Inhaltstabelle" ist im Prinzip schon richtig. Das Dateisystem hat natürlich irgendwo Platz vorgesehen, wo diese Informationen gespeichert sind.

Stöbere doch mal hier:
http://web.mit.edu/tytso/www/linux/ext2intro.html

• Wie kann man sich diese Attribute anzeigen lassen? "lsattr" bringt bei mir keine Infos:

~/Dokumente/Wiki Arbeiten/Dateisystem$ lsattr Texte.txt
------------------ Texte.txt

"Texte" wurde kurz vorher geändert und gespeichert.

"lsattr" listet nicht "normale" Attribute, sondern "erweiterte" Attribute. Schau dir mal die manpage von "chattr". Du meinst wahrscheinlich die Ausgabe von

stat Texte.txt

Das "archiv"-Attribute kenne ich übrigens nur von Microsoft-Dateisystemen...

Juhuu, ich habs kapiert!!! 😉

Vielen Dank für Deine Geduld!!!! Das wollte ich schon länger mal schreiben, aber irgendwo ist es immer untergegangen.

Ok. neuer Versuch des Einleitungtextes und den folgenden Absätzen:

Dateisysteme sind die Schnittstellen zwischen dem Betriebssystem und dem Datenträger (Partitionen). Sie organisieren eine geordnete Ablage von Daten. Als Benutzer bekommt man von der Arbeit eine Dateisystems nicht viel mit. Man sieht nur, daß Dateien oder Verzeichnisse vorhanden sind, nicht aber wo und wie diese Daten auf dem Datenträger organisiert werden. Dazu wird eine Art Inhaltstabelle eingerichtet, in der alle Dateien und Ihre Speicheradressen aufgelistet sind. Neben einer solchen grundlegenden Datenorganisation stellen die verschiedenen Dateisysteme noch unterschiedliche zusätzliche Möglichkeiten zur Verfügung. Dieser Artikel verdeutlicht einige der Unterscheide zwischen den verschiedenen Dateisysteme.

Prima! Du gehst noch etwas lax mit den Begriffen Datenträger vs. Partition um. Ich würde grundsätzlich vom Datenträger sprechen. Du kannst ja folgenden Satz einbauen:

"Obwohl Dateisysteme unter Ubuntu nicht auf die Existenz von Partitionen angewiesen sind, ist es nachwievor gängige Praxis einen Datenträger in mehrere oder zumindest eine Partition einzuteilen. Dies ist beispielsweise dann schon erforderlich, wenn weitere Betriebsysteme (z.B. Windows) mit dem Gerät betrieben werden sollen. Im folgenden wird vom Begriff Datenträger Gebrauch gemacht, unabhängig davon ob es sich nun um eine Partition oder den gesamten Datenträger handelt."

Hilfreich wäre dann eine Erklärung der Nomenklatur:
Datenträger: /dev/sd[a-z]
Partition: /dev/sd[a-z][0-9]

Hmm, wahrscheinlich reicht einfach ein konkreter Hinweis auf Datenträger

DrScott schrieb:

Du kannst ja folgenden Satz einbauen:

"Obwohl Dateisysteme unter Ubuntu nicht auf die Existenz von Partitionen angewiesen sind, ist es nachwievor gängige Praxis einen Datenträger in mehrere oder zumindest eine Partition einzuteilen. Dies ist beispielsweise dann schon erforderlich, wenn weitere Betriebsysteme (z.B. Windows) mit dem Gerät betrieben werden sollen. Im folgenden wird vom Begriff Datenträger Gebrauch gemacht, unabhängig davon ob es sich nun um eine Partition oder den gesamten Datenträger handelt."

Hmmm... ... überleg... überleg.... 💡 Ich glaube ich habe verstanden das "Linux" nicht unbedingt Partitionen braucht, um ein Dateisystem anlegen zu können: Beispiel formatierte Datei in Deinem Beispiel von oben, oder auch die Installation mittels WUBI, welche ja auch ein komplettes Betriebssystem in eine Datei packt (oder ist das bei Wubi wieder was anderes?), oder auch das InitRamFS beim Bootvorgang. Kennst Du weitere Beispiele, wo etwas anderes als Partitionen formatiert werden können?

Wenn man das so schreibt, dann müssen auch entsprechende Beispiele gegeben werden, damit man auch versteht was da gemeint sein könnte. Den Teil mit "Einteilung in Partitionen" würde ich kürzen und stattdessen auf Partitionierung/Grundlagen verweisen. Da ist dann auch das

Hilfreich wäre dann eine Erklärung der Nomenklatur:
Datenträger: /dev/sd[a-z]
Partition: /dev/sd[a-z][0-9]

beschrieben.

Man kommt wohl nicht umhin, das ganze doch noch genauer zu beschreiben. Dann wird der Artikel aber recht umfangreich. Soll man den alten Artikel einfach um einen Abschnitt "Grundlagen" erweitern, oder einen neuen Artikel Dateisystem/Grundlagen anlegen?

Egal wie es gemacht wird, es wäre nett, wenn BigMc den Artikel in die Baustelle schieben könnte.

Edit: Dein Link von oben ist wirklich sehr hilfreich und interessant! Danke!

kaputtnik schrieb:

Kennst Du weitere Beispiele, wo etwas anderes als Partitionen formatiert werden können?

Na, z.B. eine Festplatte ohne Partitionen:

sudo mkfs.ext3 /dev/sdb
sudo mount /dev/sdb /mnt

(Befehle nicht blind eintippen! Würde die Festplatte sdb komplett formatieren)
Das würde die gesamte Festplatte sdb mit einem ext3-Dateisystem belegen und anschließend in /mnt einhängen. Beachte, dass als Gerätebezeichnung /dev/sdb und nicht etwa /dev/sdb1 verwendet wird. Man kann sich /dev/sdaX als Zeiger auf die Xte Partition vorstellen. /dev/sda (ohne Zahl) ist dagegen ein Zeiger auf die Platte. Mit

sudo hexdump /dev/sdb1

würdest Du genau den Inhalt der Partition 1 sehen. Mit

sudo hexdump /dev/sdb

würde der gesamte Platteninhalt an dir vorbeirauschen, also MBR, Partition1, Partition2, usw. Natürlich nicht in dieser Struktur sondern einfach Byte nach Byte. Eben so wie das ganze auf der Platte "rumliegt".

Mit dem Zeiger /dev/sdb hast Du also Zugriff auf die gesamte Platte - über alle wie auch immer gearteten Strukturen (also z.b. Partitionen) hinweg. Es ist einfach eine andere "Ansicht" der Platte.

Indem Du die gesamte Platte formatierst, geht dadurch natürlich auch der MBR flöten. Damit verlierst Du sowohl die Partitionstabelle als auch den Bootloader. Das dürfte man also nur mit reinen Datenplatten machen, von denen nicht gebootet werden soll. Windows könnte mit so einer Platte auch nichts anfangen. Schon zwei Gründe, weshalb man diese Art der Formatierung eigentlich nicht zu Gesicht bekommt. Im Vergleich zu einer Platte mit MBR und einer einzelnen Partition gewinnt man nur einige (Kilo?)Bytes.

Daher hast Du recht: Zwar ist es prinzipiell korrekt, aus Sicht der Formatierung nicht zwischen "gesamter Platte" und Partition zu unterscheiden, praktisch gesehen ist es aber verwirrend, da für gewöhnlich eben doch nur Partitionen formatiert werden. Deshalb würde ich nun im Artikel grundsätzlich nur von Partitionen sprechen und den Begriff Datenträger dort nicht verwenden.

Den Teil mit "Einteilung in Partitionen" würde ich kürzen und stattdessen auf Partitionierung/Grundlagen verweisen.

Finde ich gut.

Man kommt wohl nicht umhin, das ganze doch noch genauer zu beschreiben. Dann wird der Artikel aber recht umfangreich. Soll man den alten Artikel einfach um einen Abschnitt "Grundlagen" erweitern, oder einen neuen Artikel Dateisystem/Grundlagen anlegen?

Da bin ich mir nicht sicher. Genausogut kann man versuchen, ihn eher hauptsächlich grundsätzlich zu halten und dann lieber in separaten Abschnitten auf Feinheiten eingehen.

DrScott schrieb:

Daher hast Du recht:

🤓 😉

Zwar ist es prinzipiell korrekt, aus Sicht der Formatierung nicht zwischen "gesamter Platte" und Partition zu unterscheiden, praktisch gesehen ist es aber verwirrend, da für gewöhnlich eben doch nur Partitionen formatiert werden. Deshalb würde ich nun im Artikel grundsätzlich nur von Partitionen sprechen und den Begriff Datenträger dort nicht verwenden.

Gut, wird gemacht.

Man kommt wohl nicht umhin, das ganze doch noch genauer zu beschreiben. Dann wird der Artikel aber recht umfangreich. Soll man den alten Artikel einfach um einen Abschnitt "Grundlagen" erweitern, oder einen neuen Artikel Dateisystem/Grundlagen anlegen?

Da bin ich mir nicht sicher. Genausogut kann man versuchen, ihn eher hauptsächlich grundsätzlich zu halten und dann lieber in separaten Abschnitten auf Feinheiten eingehen.

Genau darin liegt das Problem. Wie will man die Feinheiten verstehen, wenn man die Hintergünde nicht versteht? Mittlerweile würde ich einen neuen Untertikel bevorzugen. Es gibt bestimmt noch mehr Leute so wie ich die nicht verstehen, was ein Dateisystem eigentlich GENAU macht, oder ein falsches Bild davon haben. In diesem Hintergrundartikel könnte man dann zB auch Dein Beispiel mit der Formatierten Datei einbauen. Das kann jeder nachvollziehen und man kann dort sehr schön sehen, was passiert (Praxisbezogen). Ein solches Beispiel in den Hauptartikel zu packen, wäre definitiv zu viel.

@ MOderatoren: Bitte den Artikel verschieben!

kaputtnik schrieb:

Genau darin liegt das Problem. Wie will man die Feinheiten verstehen, wenn man die Hintergünde nicht versteht? Mittlerweile würde ich einen neuen Untertikel bevorzugen. Es gibt bestimmt noch mehr Leute so wie ich die nicht verstehen, was ein Dateisystem eigentlich GENAU macht, oder ein falsches Bild davon haben. In diesem Hintergrundartikel könnte man dann zB auch Dein Beispiel mit der Formatierten Datei einbauen. Das kann jeder nachvollziehen und man kann dort sehr schön sehen, was passiert (Praxisbezogen). Ein solches Beispiel in den Hauptartikel zu packen, wäre definitiv zu viel.

Ein Artikel, der GENAU beschreibt, was EIN BESTIMMTES Dateisystem wirklich macht, passt gar nicht hier herein. Das ist eine sehr, sehr, sehr komplizierte Sache und kann nicht mal so eben gelesen + verstanden werden. Vom Schreiben ganz zu schweigen.

Implementiere ein eigenes Dateisystem, dann könntst Du damit anfangen 😉

Man muß Kompromisse eingehen und dem Leser nicht gleich alles verraten.

@ MOderatoren: Bitte den Artikel verschieben!

Du solltest vielleicht besser einen Wiki-Teamer per PN anschreiben

Hallo,

sorry für die Verspätung, habe den Thread hier "verpasst".

Bitte schön: Baustelle/Dateisystem.

Gruß, noisefloor

Newubunti schrieb:

kaputtnik schrieb:

Mit dem letzten Artikel habe ich so meine Probleme: Eigentlich könnte er so bleiben, andererseits wird keine klare Trennung zwischen Dateisystem und Verzeichnisstruktur vorgenommen. Es geht um den Abschnitt Wie-die-Daten-abgelegt-sind-Die-Software-Ebene. Was sagt ihr?

Mir gefällt der Abschnitt auch nicht. Insbesondere vermittelt er den Anschein, als seien Dateisystem, LVM und Partitionen gleichberechtigte Ordnungseinheiten nebeneinander. Es ist aber so, dass sie in einer Hierarchie zueinander stehen.

Man könnte das umsortieren, aber man sollte auf jeden Fall mit Partitionen und dann dem Dateisystem anfangen, denn das ist es, dem die meisten neuen Nutzer als erstes begegnen - und es handelt sich bei Datenverwaltung um einen Einsteiger-/Grundlagen-Artikel!

Wenn man mit LVM einsteigt, könnte der Eindruck entstehen, dass sei etwas "notwendig" - der LVM ist jedoch nach wie vor etwas für "Experten".

Sofern physikalische Datenträger in Partitionen aufgeteilt oder zu LVMs zusammengefasst werden können, sind diese beiden Ordnungsformen dem Dateisystem übergeordnet. D.h. eine Partition enthält ein Dateisystem und ein LVM nimmt auch ein solches auf.

Partitionen werden nicht zu "LVMs" zusammengefasst, sondern allenfalls zu LVs und ein Logical Volume nimmt ein Dateisystem auf (LVM=Logical Volume Manager) 😉

Ein Dateisystem enthält aber niemals ein LVM oder eine Partition. Das geht bis jetzt nicht aus dem Abschnitt hervor.

Gut, ich werd mir mal Gedanken dazu machen, wie man das klarer machen kann.

Im übrigen krankt der Artikel auch daran, dass auf die Hardwareebene nur unzureichend eingegangen wird. In irgend einem der Artikel um Dateisysteme und Datenträger sollte auch mal darauf eingegangen werden, wie die physikalische Beschaffenheit der Datenträger schon eine gewisse Struktur vorgibt - wie das z.B. bei Festplatten durch Scheibe, Kopf und Spur der Fall ist. Das gehört für mich zur Hardwareebene dazu.

Einspruch! Es handelt sich um einen Grundlagen-Artikel für Ein- oder Umsteiger! Du kannst darin doch den Leuten nicht ernsthaft den hardware-technischen Aufbau einer Festplatte erklären wollen. Da kannst du ja gleich mit den physikalischen Grundlagen wie Magnetisierung usw. anfangen ...

Am besten würde das bei Datenträger passen. Oder man beschreibt das in einem Grundlagenartikel für Datenträger.

Da wäre ich schon eher d'accord. Ich weiß aber nicht, ob wie hier zwangsläufig ein "elektrotechnisches" Unter-Wiki aufmachen sollten/müssen ...

BG S*