Assistant DiskStation schematischer Aufbau

Status
Für weitere Antworten geschlossen.

Matthieu

Benutzer
Mitglied seit
03. Nov 2008
Beiträge
13.222
Punkte für Reaktionen
88
Punkte
344
Aufgrund einer Diskussion über Netzwerke hab ich mich mal mit dem Thema Visualisierung mit Programmen wie Visio beschäftigt. Da ich aber kein Visio erwerben möchte, bin ich bei einer Suche auf "Dia" gestoßen.

Die Chance habe ich mal genutzt um den Aufbau der DiskStation (softwareseitig) ein wenig vereinfacht darzustellen.

Im Anhang die momentane Version. Bei Fehlern bitte unbedingt bemerkbar machen!

MfG Matthieu

@itari: Das ganze steht unter GPL 3 :D

EDIT: Achtung! Hier entsteht eine Diskussion, das heißt dieses Bild wird noch überarbeitet! Bitte zu den neueren Posts für den aktuellen Stand gehen, da die älteren Bilder durchaus Fehler beheimaten können!
 

Anhänge

  • DiskStation_Dia1.jpg
    DiskStation_Dia1.jpg
    42,8 KB · Aufrufe: 188
Zuletzt bearbeitet:

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
Bilder haben verschiedene Wirkungsebenen: sie machen Zusammenhänge einfacher und verknüpfen Zusammenhänge im Gehirn, so dass man den Bildern mehr glaubt als der Wirklichkeit, weil sie sich sozusagen wie ein Filter dazwischen schieben.

Da ich das Bild sehr hübsch finde, will ich jetzt kein neues entwerfen, sondern einfach Fragen stellen, die vielleicht durch leichte Überarbeitungen des Bildes (und vielleicht durch 'schwere' Überarbeitungen im Kopf) dann deutlicher werden.

- Was macht/tut eigentlich die Synology-Firmware in dem Bild?
- Wieso kommen die Datenpakete des Netzwerkes nicht durch einen (Hardware-)Netzwerkadapter, sondern schleichen sich so von der Seite an?
- Wieso sind die Datenbanken so weit weg vom Betriebssystemkernel (Dateisystem), obwohl sie doch am meisten mit Dateien zu tun haben?

Das mit der GPL3 ist lieb; bei inhaltlichen Texten ist die CC trotzdem angemessener - so wie bei unserem Wiki ja auch. ;)

Ich hoffe jetzt auf eine spannende Diskussion, denn ich finde die Idee mit der bildhaften Darstellung super. :)

Itari
 

Matthieu

Benutzer
Mitglied seit
03. Nov 2008
Beiträge
13.222
Punkte für Reaktionen
88
Punkte
344
Mit der Firmware hast du recht ... das macht relativ wenig Sinn :rolleyes:
Das mit der Hardware hatte ich aus einem anderen Grund gemacht, aber mit ein paar Veränderungen funzt das auch.
Nur das mit dem Dateisystem ist so eine Sache. Hatte lange gegrübelt ob und wenn ja wie ich es integriere. Hab es jetzt mal über die Hardware als separate Schicht gelegt.

In meiner Vorstellung baut sich nach dem neuen Aufbau allerdings ein Problem zwischen Dateisystem und nobody-Apache bzw. Webstation auf. Die Hardware ist für ihn ja definitiv tabu, das hab ich schon so dargestellt, aber wie sieht es mit dem Dateisystem aus? Inwiefern ist der Web-Ordner als Teil des Dateisystems als ganzes zu betrachten?

MfG Matthieu
 

Anhänge

  • DiskStation_Dia1.jpg
    DiskStation_Dia1.jpg
    42,3 KB · Aufrufe: 164

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
Ja, das mit dem Dateisystem ist so eine Sache. Was ist alles das Dateisystem?

Zunächst werden ja unter Linux/Unix alle Daten, die Programme ein-/oder ausgeben (egal ob auf einen Datenträger, eine Netzwerkschnittstelle oder ein Ein-/Ausgabegeräte wie Bildschirm, Drucker, USB-Sound) über Kernel-Funktionen (Treiberaufrufe, Dateisystemaufrufe) abwickelt. Das Dateisystem wäre demnach komplett im Kernel genauso wie diese Ein-/Ausgabe-System-Call-Schnittstellen.

Man kann sich das Dateisystem als eine höhere Schicht vorstellen, die primitivere Schichten bedient und dabei die eigentliche Natur der Hardware vor den Programmen versteckt.

Auch die Kommunikation über Sockets, Pipes usw (Interprozeßkommunikation im weitesten Sinne) wird über das Dateisystem abgewickelt, so z.B. auch die Kommunikation zwischen Apache und MySQL/Postgres-Datenbankservern.

Im Wesentlichen gibt es in Betriebssystemen halt zwei Objektarten:

- Prozesse/Threads als Räume für ausgeführte Programme, welche untereinander per Prozesskommunikation ihre Datenobjekte austauschen und

- Streamobjekte, die im Linux-Kernel als Schnittstellen für die Datenkommunikation zwischen (nichtverwandten) Prozessen (Interprozeßkommunikation) und als Zugang der Prozesse zu Hardwareressourcen (Ein-/Ausgabe, RAM, Netzwerk, Platten) genutzt werden

Letzte können wie gesagt, durch eine Strukturunterstützung (Dateisystem, Netzwerkprotokolle usw.) abstrahiert werden.

Im übrigen ist der Aufbau von Linux und Windows nicht ganz so verschieden.

http://www.ibm.com/developerworks/linux/library/l-linux-kernel/
http://de.wikipedia.org/wiki/Linux-Kernel
http://de.wikipedia.org/wiki/Microsoft_Windows_XP#Hardware_Unterst.C3.BCtzung

Itari

PS. Ich finde es gut, dass wir dieses Thema im Forum behandeln :)
 

Matthieu

Benutzer
Mitglied seit
03. Nov 2008
Beiträge
13.222
Punkte für Reaktionen
88
Punkte
344
Anscheinend stützt du dich größtenteils auf den Artikel von IBM. Mit dem Kernel selbst hab ich mich vor einiger Zeit aus anderen Gründen schon mal beschäftigt, aber nicht so sehr ins Detail.

Im dortigen Artikel wird das ganze als Virtual File System bezeichnet, richtig?
Ich seh momentan in der Grafik das Problem, dass sich zum einen das Dateisystem schwer direkt zuordnen lässt, da man ja nicht genau sagen kann wo Zugriff aufs Dateisystem beginnt und endet und außerdem ist es eine ziemlich dicke Schicht über der Hardware, die der eigentlichen Hardware ziemlich viel Platz klaut. Ich hatte zum Beispiel auch darauf geachtet was rechts oben mit Hardware und Anwendungen passiert, da ja einige Zugriff haben, aber bei weitem nicht alle. Ich finde daher die Grenzen der Hardware verschwinden ein wenig unter dem Dateisystem. Ich würde daher gerne das Dateisystem als solches aufteilen in den Teil, er Daten als solche speichert und den Teil wo er über der Hardware zur "Vereinfachung" liegt. Was haltet ihr davon? Wie könnte man das dann bezeichnen?

MfG Matthieu
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
Der Gedanke bei Linux/Unix usw. ist, dass der Kernel samt Treiber die Hardware "versteckt" (kapselt), so dass man nur über der Kernel auf die Hardware zugreifen kann. Das gleiche gilt für das Dateisystem: auch hier will man das byteweise Zugreifen auf die Geräte gegen ein strukturelles Zugreifen (Dateien, Verzeichnisse, Berechtigungen usw.) verstecken und möglichst alles über diese 'Schleimschicht' abwickeln. Das Dateisystem (z.B. ext3) ist nicht wirklich für die Datenspeicherung zuständig, sondern stellt nur die Ordnungsmechanismen (Dateinamen, Verzeichnis, Volume) für die Speicherung zur Verfügung.

Itari
 

Matthieu

Benutzer
Mitglied seit
03. Nov 2008
Beiträge
13.222
Punkte für Reaktionen
88
Punkte
344
Also hat nur das, was direkt auch auf die Hardware kommt, direkten Zugriff aufs Dateisystem. Dann wäre die extra-Schicht fürs Dateisystem nicht notwendig, oder?

MfG Matthieu
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
Also hat nur das, was direkt auch auf die Hardware kommt, direkten Zugriff aufs Dateisystem. Dann wäre die extra-Schicht fürs Dateisystem nicht notwendig, oder?

Anders herum wird ein Schuh draus: Kein Programm kann direkt auf die Hardware zugreifen, sondern nur vermittelt via Dateisystem und Kernel.

Itari
 

Matthieu

Benutzer
Mitglied seit
03. Nov 2008
Beiträge
13.222
Punkte für Reaktionen
88
Punkte
344
[..] sondern nur vermittelt via Dateisystem und Kernel.
Also stellst du Kernel und Dateisystem auf eine Ebene?
Dann müsste ich das Dateisystem ein wenig anheben und neben den Kernel legen ...

MfG Matthieu
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
Der Linux/Unix-Kernel besteht aus:

- den Treibern (Schnittstellen zu Hardware - alles was in /dev ist)
- den (virtuellen) Dateisystemen (ext3, RAID, Netzwerkstacks, /tmp usw.)
- dem Prozesssystem (Time-Sharing-Scheduler, Signale, usw.)
- dem Memorymanagement (des RAMS, Swap usw. )
- der System-Call-Schnittstelle
- dem Interprozesssystem (Shared Memory, Semaphoren, Message Queuing, Sockets usw.)
- diversen Systemüberwachungseinrichtungen (sind meist auch Dateisysteme: /sys, /proc)
usw usw.

Manche sagen auch, dass die (Standard-)Bibliothek(en) /lib noch zum Kernel zählen. Andere wollen auch, dass der Init als Kernelprozess noch dazu zählt. Kann man sehen, wie man mag.

Der Kernel ist sozusagen die Sammlung aller Teile, um die komplette Hardware zu kapseln und Programme mit einem Schnittstellen-Environment zu Dateisystemen auszustatten und ausführbar zu machen.

Itari
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
Langsam bin ich ratlos wie man sowas umsetzen soll ...

MfG Matthieu

Ich würde das Dateisystem/Interprozesskommunikation in den Kernel als Block integrieren.

Die Apaches, telent/ssh, Datenbank-Manager usw. nebeneinander, welche über die Sockets (im Kernel) kommunizieren. Alles was sonst noch wäre, würde ich den Apaches als Anwendungsschicht (wie du es ja auch schon gemacht hast) zuordnen.

Itari

PS. nicht verwirren lassen, aber das wäre der Kernel in seiner ganzen Pracht:
http://en.wikipedia.org/wiki/File:Linux_kernel_map.png
 
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat