Da hast du recht - haben wir nicht!
Aber ich denke schon, dass wir zumindest schon mal davon gehört
haben sollten!
gut das haben wir jetzt wohl 
Eine frage:
Können denn Hardlinke auch noch auf Verzeichnisse verweisen und ob nur Systemadministrator sie anlegen kann?
Ich denke hardlinks können auch auf Verzeichnisse verweisen.
Falsch ist allerdings dass sie nur vom systemadministrator angelegt werden können…
Eine Klausur in der die Frage dran kommt ,wurde weiter oben besprochen…
hardlinks können nicht auf Verzeichnisse verweisen, soviel ich weiß
Hardllinks können nicht auf Verzeichnisse verweisen und
können auch von normalen Usern angelegt werden - soweit ich
das noch in Erinnerung habe…
Hardlinks können auf Verzeichnisse verweisen (… und . sind Hardlinks auf das übergeordnete bzw. aktuelle Verzeichnis). Hardlinks auf Verzeichnisse können in
der Regel nicht von Benutzern angelegt werden, auf normale Dateien aber schon.
Das Ganze verwirrt mich grad ein bisschen…
Ein Verzeichnis ist doch auch eine Datei…samt I-node usw. .
Und da steht u.a. anderem die Anzahl der Hardlinks drin.Bei einem Verzeichnis sind das i.d.R. “2”,nämlich die Referenz von übergeordneten Verzeichnis und einmal die selbstreferenz “.” ???
Schaut auch mal bitte auf Folie 7-34…
EDIT: stefan siehts ja auch so…
Da ist dann wohl ein fehler in der Sos Klausur vom September 2004
http://www4.informatik.uni-erlangen.de/Lehre/SS04/V_SOS1/Pruefung/2004s-SOS1-Klausur-www.pdf
(Frage d)
da hat Stefan wohl doch recht…
Das bedeuted, dass man als Superuser auch Hardlinks auf
Verzeichnisse setzten darf. Soweit ich das mitbekommen hab’
soll man das aber vermeiden, da man ein ganz schönes Gewurschtel erzeugen kann - nur dann wenn man ganz genau weiß, was man
da macht… Als normaler User kann man also hardlinks nur
auf Dateien setzten -
Jedes Verzeichnis ist mit “.” mit sich selber verlinkt (hardlink) und
“…” dann quasi mit seinem Übergeordneten Verzeichnis verlinkt…
die semget, semctl, shmatt, … Schnittstellen muesst Ihr nicht beherrschen.
Was ein Sharded Memory Segment ist (also was das z.B. mit einer
segment-Tabelle oder page table zu tun hat) sollte man aber schon wissen.
Aus heutiger (Vorlesungs- und Uebungs-)Sicht ist die Antwort
„Ein Hard-Link kann nur auf Dateien, jedoch nicht auf Verzeichnisse verweisen“
falsch. Wir haben das Thema damals etwas anders gebracht: man kann
tatsachlich keine Hard-Links auf Directories mit dem link-systemcall
anlegen (frueher ging das mal als mkdir noch kein Systemcall war und das
mkdir-Programm . und … einzeln erzeugen musste - aber wenn der
Rechner dazwischen abgestuerzt ist, dann hatte man einen ziemlich
inkosistenten Zustand im Dateibaum).
Aber das Betriebssystem legt im Rahmen von mkdir tatsaechlich
Hard-Links auf Directories an (mindestens einen mit dem Directory-Namen
im Directory drueber und den Link . im Directory selbst. Falls es
Unterdirectories gibt, beim Anlegen jedes Unterdirectories dort einen
mit Namen …). Damit koennen Hard-Links tatsaechlich auch auf Directories
verweisen.
In der SS2004-Klausur 1d sollte damals die erste Antwort angekreuzt
werden.
Heute wuerde ich die Aussage 2 nicht mehr so formulieren.
bitte löschen ^^
Welche Art der Kommunikation liegt bei einem write-Aufruf an einem Socket (mit
bereits aufgebauter TCP-Verbindung) vor?
❏ Synchrone IPC mit sendeseitiger Synchronisation
❏ Synchrone IPC mit Client-seitiger Synchronisation
❏ Asynchrone IPC mit pufferblockierendem Senden
❏ Asynchrone IPC mit unzuverlässigem Senden
- würde ich ausschließen,
im Stevens steht “by default sockets are blocking” wenn ich das richtig verstehe meint er damit dass die Verbing synchron ist.
Also bleibt noch 1 und 2.
Ist das so dass der Sender schickt und so lange blockt bis gelesen wurde?
Wenn ja wär 1 richtig, oder?
Wenn ich die Folie 7-96 richtig verstanden habe, würde ich 3 antworten. Oder?
Hm, ich komm mit der Meinung von “synchron” und “asynchron” nicht zurecht…
Man könnte synchron dahin deuten, dass die eine Seite mitbekommt, wann die andere was reingesteckt hat. Das kommt ja aber eher von den Auslesebefehlen, die erst dann zurück kommen (oder???)
Und asynchron könnte man so sehn, dass gemeint ist, dass die zwei seiten zeitlich entkoppelt sind. Also quasi ein Puffer drin ist, der die beiden Seiten trennt… Man kann sozusagen rein schreiben und raus lesen “wann man will”.
Da es ja nicht direkt einen Interrupt gibt, wenn daten in der Röhre liegen würde ich eher auf asynchron tippen.
Pufferblockierend klingt gut. Weiß ich aber net, hatte noch nie nen Röhrenüberlauf…
Ahhh… Auf 7-102 steht definitiv asynchron! und das also “Contra” und mit der Aussage, dass es schwer wäre eine synchrone Verbindung nachzubauen.
Es könnte allerdings auch unzuverlässig sein. Allerdings würde man bei dem Fall benachrichtigt. Oder kann es sein, dass sowas verloren geht? Soll heißen, ist das Protokoll mit Fehlererkennung? So dass die Daten nochmal angefordert werden, wenn sie fehlerhaft waren?
ja TCP fordert die Daten nochmal an, wenn sie fehlerhaft waren, oder die Annkunft nach einer Weile nicht bestätigt wurde und ist deshalb zuverlässig.
UDP schickt die Daten nur einmal und kümmert sich nicht darum ob sie ankommen und ist deshalb unzuverlässig.
Weiß jemand was “Sockets blockieren” bedeutet?
Die Frage nervt mich (unter anderem ;-)) auch schon die ganze Zeit. Da es sich um eine TCP-Verbindung handelt, würde ich prinzipiell (1) ankreuzen. Andererseits ist write auf jeden Fall “asynchron” und “pufferblockierend” implementiert (wobei das mit dem “pufferblockierend” auch so eine Sache ist, write gibt halt einen Fehler zurück, wenn der Puffer voll ist, also es ist zumindest nicht “unzuverlässig” Stimmt nicht ganz: Die man page geht nicht so genau d’rauf ein, aber write scheint zu blockieren, wenn der Puffer voll ist) und weiß ja nichts über das Medium auf dem die Daten transportiert werden (also ob in eine Datei geschrieben wird, auf einen Socket, etc.).
Die Frage ist jetzt: Ist nur der write-Aufruf gemeint oder die komplette Verbindung?
Also ich assoziiere bei sowas “synchron” mit ner RPC-Semantik und
“asynchron” mit message-passing, wobei mir die Implementierung erstmal egal ist.
die detaillierte Erlaeuterung zu dieser Frage hatten wir nur im SS2004 in der SOS-Vorlesung.
Seit letztem Jahr haben wir das wieder weggelassen.
Wen’s interessiert: Skript vom SS2004, Seite 8-21 bis 8-26.
Das Thema kommt sicher nicht in der Klausur dran.
Insofern muesst Ihr bei alten Aufgaben ab und an vorsichtig sein - der Stoff hat sich immer
wieder ein wenig geaendert. Nicht wild - aber manche Themen sind inzwischen einfach nicht
mehr in der Vorlesung drin. Gegenueber 2005 ist’s aber fast 100% identisch.
Nachdem etliche jetzt schon drueber gehirnt haben verrat’ ich zumindest noch die
Aufloesung 
Die Loesung waere 3.
Das write blockiert nicht so lange bis der Empfaenger die Daten hat, sondern nur so lange
bis ein Puffer zur Ausnahme der Daten bereit steht. In Bezug auf die Interprozesskommunikation
mit dem Empfaenger ist das write also asynchron. Es erfolgt aber eine Synchronistaion
mit dem Pufferungsmechanismus in der Kommunikationsschicht (also im Kern des
Senders und im Systemkern des empfangenden Rechners). Wenn die PUffer voll sind,
dann blockiert das write. Letztlich analog zu einer Pipe.
@juk, danke für die Antwort.
Jetzt häng ich bei einer neuen Frage:
Welche Aussage zu Speicherzuteilungsverfahren ist falsch?
❏ die worst-fit-Strategie kann einem mit der kürzesten Antwortzeit einen ausrei-
chend großen Speicherbereich liefern
❏ best-fit arbeitet mit konstanter Komplexität und ist deshalb das beste Verfahren
❏ first-fit hat konstanten Aufwand bei der Verschmelzung von Lücken
❏ bei buddy-Verfahren gibt es keinen externen Verschnitt
Für mich klingen zuwohl 2 als auch 3 falsch…
Zu 2: Wie soll best-fit mit konstanter Kompläxität arbeiten? Im günstigsten Fall, wenn die Freispeicherliste nach Größe sortiert ist, ist der Suchaufwant immer noch logaritmisch zur Listengröße.
Zu 3: Konstanter Aufwand bei der Verschmelzung von Lücken? Mir fällt spontan nur die Möglichkeit ein Speichersegmete zu verschieben, und das dauert…