Re: iSCSI initiator

On Fri, Jun 20, 2003 at 11:45:36AM +1000, Peter Ross wrote:
> Hi,
>
> vor vielleicht zwei Wochen habe ich hier ja mal ein bisschen ueber einen
> NFS-Proxy o.ae. gesprochen.
>
> Daraus ist dann, auch durch eine Mail in der
> freebsd-cluster-Mailingliste, eine andere Idee geworden - ein
> iSCSI-Initiator.
>
> Ich will mich mal dran versuchen, es wird, wenn es klappt, mein erstes
> "Kernelwerk", bin also noch echt Newbie mal wieder.
>
> Nach einigem Lesen ueber iSCSI und der mehr oder minder gelungenen
> FreeBSD-Installation (sieht man mal von "Homecomputer-Features" wie den
> Scanner ab) moechte ich nun loselegen.
>
> Ich traue mich hier mal etwas unbefangener Anfangsfragen zu stellen..
>
> Nur kurze Minimalerklaerung von iSCSI fuer nicht so Involvierte: es ist
> SCSI ueber IP. Statt auf ein lokales SCSI-Device zuzuggreifen, werden die
> Befehle in TCP-Pakete gepackt und uebers Netz geschickt, der Empfaenger
> entpackt die Pakete und schreibt dann bei sich. So sind SCSI-Devices (oder
> auch Emulationen, wenn der Server das kann) uebers Netz erreichbar.
>
> Der Client heisst iSCSI-Initiator, der Server iSCSI-Target.

Initiator und Target sind Begriffe, die du auch auf traditionellem SCSI
hast.
Als Alternative zu iSCSI gibt es übrigens auch schon wesentlich länger
NDMP, welches ursprünglich einen anderen Zweck hatte, aber letzlich
ebenfalls (als Anhängsel) die Möglichkeit bietet raw mit SCSI Geräten
auf Servern zu sprechen.

> Am iSCSI-Initiator will ich mich mal versuchen. Der besteht m.E. aus zwei
> Teilen: dem "Netzwerkteil", welcher nach Targets guckt (es gibt auch
> einen Nameservice dafuer) und die Verbindungen aufbaut, sich beim Target
> authorisiert etc. und dann diese TCP-Verbindung bereitstellt. Ein Daemon.
> Ich stelle mir derzeit vor, dass ich fuer jede iSCSI-Verbindung eine
> Instanz forke.

Es hat Vorteile das komplett im Kernel zu machen, damit kannst du z.B.
auch die / Platte auf einem iSCSI Laufwerk haben.
Außerdem hast du bei einem Userland Programm einiges mehr zu beachten,
um low Memory Deadloks zu verhindern.
Die Konfiguration kannst du am besten mittels eines /dev/iscsi.ctl
und ein paar selbst definierten ioctl machen.

> Und dem SCSI-Device im CAM-System, wenn ich das richtig sehe.
>
> Ist es richtig, dass dieser ein SIM-Treiber sein muesste, der zum Schluss,
> statt etwas an einen SCSI-Adapter zu schicken, seine Kommandos an den
> Netzwerk schickt?

Ja - SIM ist ein SCSI Interface Module und repräsentiert den (logischen)
Host Controller.

> Wenn ja - welcher Weg bietet sich zur Kommunikation mit dem Daemon an? Ein
> Kontrollsocket?

Wie schon gesagt solltest du das komplett im Kernel realisieren.
In dem Fall bieten sich upcall Funktionen an.
Du brauchst nicht mal einen eigenen Thread fürs die Software, da sowohl
das Netzwerksystem, als auch CAM im Kernel bereits Ereignissorientiert
sind.

> Und umgekehrt - wie schickt der Daemon seine Daten, wenn er z.B. gelesen
> hat, oder auch eine SCSI-Kontrollmessage an den SIM?

Genauso - die Netzwerkverbindung ruft mit eingehenden Daten deinen
Netzwerkcode auf und dieser kann dann gegebenenfalls den CAM code
aufrufen.

Es gibt einen Kernel Developer Guide, den du in den benötigten
Abschnitten lesen solltest.
Gerade CAM ist gut Dokumentiert.

> Entschuldigung, dies sind mehr oder minder erst einmal Design-Fragen eines
> noch etwas Unbedarften. Aber irgendwann muss man ja anfangen - und wenn's
> nicht fertig wird, haette ich trotzdem vielleicht ein bisschen was
> gelernt. Aber noch bin ich guter Hoffnung:-)

Wie schon erwähnt - fange mit dem Kernel Developer Guide an.
Für das generelle Vorgehen ist auch immer noch das 4.4BSD Design
and Implementation gut geeignet, auch wenn du das dann auf die aktuelle
kernel Syntax anpassen mußt.

-- 
B.Walter                   BWCT                http://www.bwct.de
ticso(at)bwct.de                                  info(at)bwct.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message