Arch Linux

iSCSI, eieiei...

spleen

Da habe ich jetzt meine ganz tolle WD MyCloud-NAS mit 2x4TB RAID1; neu, aber Hardware + BIOS wohl von 2014.

Da sollen iSCSI-Laufwerke (= targets/Ziele mit <iqn>, nehme ich an) drauf, die von Arch aus (= initiators) erreichbar bzw. automatische gemountet werden sollen. – Aber wahrscheinlich würde mir 1 ausreichen, denn da kommen nur jede Menge Dateien rein zum Sharen im Heimnetz.

iSCSI-Ziele (sowie -Clients) als solche lassen sich im MyCloud-Backend erstellen (bereits einmal gemacht und wieder gelöscht). Wie kann ich die dann mit LIO/targetcli auflisten/ansprechen/registrieren...?
Brauche ich targetcli überhaupt?
(Ich denke schon wenn als systemctl "enabled", um targets mounten zu können [die dazu erst noch eine Partiton mit Dateisystem haben müssen].)
Oder sollte ich von vorn herein nur targetcli ODER MyCloud-Tools benutzen?

Und wie groß sollte ein Ziel am besten sein? Mache ich sie zu groß, kriege ich Warnungen und eine LED leuchtet rot – selbst wenn das Target ganz leer ist. Denkbar wäre 3 TB iSCSI + Rest über NFS.

Und wo kommen da die LUNs ins Spiel?
Brauche ich diese überhaupt?

Also, das LIO Admin Manual.pdf bzw. Wiki ist mind-blowing! Das fängt mit irgendwelchen RAID-Controllern an, von denen ich nicht mal weiß, welcher von den beiden genannten Dingern bei der MyCloud drauf sind, und ob das hier überhaupt relevant ist...

Die MyCloud hat natürlich eine IP. Aber wie nutze ich die für targetcli, um damit etwa ein Ziel (nicht auf der Arch-Box) zu erstellen bzw. ein bereits vorhandenes anzusprechen?

Die Wikis von Arch oder Ubuntu geben mir leider wenig bis nichts auf meine Fragen.

Am besten finde ich noch die Anleitung von RedHat.

Trotzdem stehe ich da auf dem Schlauch...
Was sind eure Erfahrungswerte?

frostschutz

Die roten Warnhinweise hast du gelesen?

https://support-en.wd.com/app/answers/detailweb/a_id/3864#subject8

Vielleicht habe ich dich falsch verstanden, aber bei deinem genannten Anwendungsfall ("jede Menge Dateien rein zum Sharen im Heimnetz") wäre iSCSI möglicherweise nicht das richtige...

spleen

frostschutz
Welche roten Warnhinweise..?

Also, das Teil soll nur über LAN laufen und nicht nach draußen bzw. mit einem Smartphone verbunden sein.

Au0erdem wollte ich die Partition/en darauf verschlüsseln.

frostschutz

Die WD Seite scheint keine direkten Verlinkungen zu mögen, dann musst du dich eben durch die einzelnen Punkte durchklicken.

Important:
iSCSI is NOT a sharing protocol.
iSCSI is a method of connecting to a "drive" using TCP/IP over SCSI. There is no communication between the iSCSI Initiators. Unless using a filesystem that is specifically designed to support file locking, data loss can occur when attempting to connect two or more iSCSI Initiators to the same iSCSI Target.

Draußen/Smartphone spielt keine Rolle. Auch im LAN kannst du das nicht sharen — oder wenn dann nur so, daß immer nur einer Zugriff darauf hat. Oder alle machen Read-Only und halten sich dran. ("alle readonly und nur einer schreibt" geht auch nicht.) Es sei denn du nimmst tatsächlich ein Cluster-Dateisystem dafür her.

iSCSI ist ein wenig speziell, und auch sonst arg fehlerträchtig. Netzwerkverbindung mal kurz weg? Ja schön, dann ist dein Dateisystem eben korrupt. Pech gehabt... im Serverbereich ist das eine Sache, im Heimgebrauch trifft man das normalerweise nicht an.

spleen

Ach so, ich dachte, die WDCloud wäre im Prinzip so eine Art Fileserver...
Also würde iSCSI generell hier nur etwas bringen, wenn darauf ein bootendes OS + targetcli installiert wäre?

Ich dachte halt, es wäre schneller und gewissen robuster als NFS. Und ich dachte, ich könnte dann die (verschlüsselten) Partitionen im fstab einbinden.

Also dann doch nur NFS und ggf. SMB mit halt verschlüsselten Ordnern (veracrypt)?

frostschutz

Einbinden kannst du das dann schon, nur eben nicht auf 2 Rechnern gleichzeitig. Von deiner Beschreibung her klang das nicht so als ob du das so willst, denn NAS hat man ja normal, daß jeder jederzeit und auch gleichzeitig auf Dateien im Netz zugreifen kann.

Bei NFS können im Prinzip mehrere gleichzeitig. Dafür ist das Protokoll ja gerade da. Aber auch hier: wenn zwei gleichzeitig an der gleichen Datei rumfummeln, gibts womöglich Probleme. Also cryptsetup/veracrypt Containerdateien wären da auch nicht gleichzeitig bearbeitbar.

Ein Dateisystem mounten kann / darf immer nur einer auf einmal. Gleiches Problem wenn du das in einer Containerdatei versteckst.

Deswegen gibts ja gerade diese Protokolle, die unabhängig vom Dateisystem nur Dateien übers Netzwerk schubsen - während das Dateisystem selbst tatsächlich nur von einem Punkt aus kontrolliert wird (dem NAS eben). Und deswegen geben Smartphones ohne weiteres keine Blockdevices mehr raus sondern machen auch über USB nur noch den MTP Quatsch. Die Kontrolle über das Blockgerät & Dateisystem hat hier nur das Smartphone selber.

spleen

Aha.
Das heißt, auch bei NFS können nicht z. B. zwei Rechner gleichzeitig bzw. sukzessive auf denselben Veracrypt-Container zugreifen?

Und von verschiedenen Rechnern/mit verschiedenen Usern schreibend auf dieselbe Datei zugreifen hatte ich nicht vor, aber lesen könnte ja vielleicht sein.

frostschutz

Lesen geht, aber das muss dann tatsächlich im Readonly-Modus geöffnet werden, denn Dateisysteme schreiben sonst bereits beim Mountvorgang auch wenn du jetzt selber keine Datei innerhalb des Containers verändern willst.

Und wenn einer schreibt, dann dürfen die anderen das auch nicht gerade Readonly gemountet haben, weil Readonly impliziert eben auch, daß sich der Zustand auf der Platte nicht einfach so verändert. Passiert das doch, dann sieht der Readonly-Client auf einmal korrupte Daten, weil der das veränderte Dateisystem noch von einem alten Stand her interpretiert (veraltete Datenstrukturen im RAM des Clients auf die die Änderungen nicht durchschlagen).

Daher wenn einer schreiben will, müssen alle andern erstmal raus.

spleen

frostschutz Lesen geht, aber das muss dann tatsächlich im Readonly-Modus geöffnet werden, denn Dateisysteme schreiben sonst bereits beim Mountvorgang auch wenn du jetzt selber keine Datei innerhalb des Containers verändern willst.

Also, dann geht das: Ein Rechner hat den NFS+VC-Container bereits geöffnet, für den zweiten ist er noch zu, kann den aber trotzdem öffnen.

Müsste doch eigentlich gehen – wäre ja so, wie wenn beide auf denselben unverschlüsselten Ordner zugreifen.

frostschutz Und wenn einer schreibt, dann dürfen die anderen das auch nicht gerade Readonly gemountet haben, weil Readonly impliziert eben auch, daß sich der Zustand auf der Platte nicht einfach so verändert. Passiert das doch, dann sieht der Readonly-Client auf einmal korrupte Daten, weil der das veränderte Dateisystem noch von einem alten Stand her interpretiert (veraltete Datenstrukturen im RAM des Clients auf die die Änderungen nicht durchschlagen).

Daher wenn einer schreiben will, müssen alle andern erst mal raus.

Trifft das auch auf Ordner zu?
Also darf dann der eine nicht lesen (etwa ls oder eine Datei ro-lesen), während der zweite in den Ordner bspw. eine Datei kopiert?

spleen

Wenn ich das also richtig verstanden habe, kann man ein iSCSI-Ziel nur auf einem Server installieren, Server heißt laufendes Betriebssystem. Das heißt auch, auf der MyCloud läuft ein BS, sonst könnte man dort auch gar kein Ziel erstellen, selbst wenn man das im Browser auf der Arch-Kiste machen kann. Und zur NAS-IP kann man ja auch hin ssh'en.

Und das heißt auch: Weil targetcli für speziell Ziele ausgelegt ist (wenn ich das richtig verstanden habe), macht das gar keinen Sinn, das auf meinem Arch-PC laufen zu lassen, weil da ja kein Ziel drauf kommen soll (sondern es soll sich höchstens mit einem verbinden)...

frostschutz

spleen Trifft das auch auf Ordner zu?
Also darf dann der eine nicht lesen (etwa ls oder eine Datei ro-lesen), während der zweite in den Ordner bspw. eine Datei kopiert?

NFS erlaubt das natürlich. Kein Problem - es ist nur, wenn du mehrere Prozesse hast die um den gleichen Ordner / die gleiche Datei kämpfen. Da kannst du natürlich auch Probleme bekommen, also das geht dann in Richtung threadsafe / race condition. Diese Probleme gibt es lokal ja auch schon, bei Dateisystem-Operationen die nicht atomic sind.

Aber das macht man ja normal einfach nicht, also jetzt z.B. zwei rsync-Prozesse statt nur einen gleichzeitig laufen lassen die dazu auch noch die gleichen Dateien übertragen wollen. Bestenfalls wird dann halt unnötig mal was doppelt kopiert. Schlechtestenfalls würden die sich gegenseitig kaputt schreiben. rsync hat aber eigene Sicherheitsvorkehrungen für Fälle in denen es Konflikte gibt. So werden neue Dateien erstmal unter anderem Namen erstellt und erst wenn die Datei vollständig ist, zum richtigen Namen umbenannt (und das umbenennen an sich ist atomic, zumindest bei lokalen Dateisystemen). So gibt es dann nicht den Fall daß da ein anderer Prozess eine Datei wegkopiert die gerade nur halb da ist (und damit dann korrupt wäre) weil ein anderes rsync da erst noch am kopieren war. Und NFS macht da auch so ähnliche Sachen.

Normalerweise passiert da nichts aber wenn man es besonders drauf anlegt sind da natürlich auch Probleme möglich.

frostschutz

Wenn dein NAS von sich aus ein iscsi target bereitstellt (was es ja muss, wenn das am Ende auf dem NAS gespeichert werden soll) dann brauchst du selber kein target erstellen, völlig richtig.

Wenn du ein target erstellst und das NAS sowas unterstützt dann kann das NAS auf deinen lokalen Speicher zugreifen. Aber du selber dann halt nicht. Jedenfalls nicht in Form eines gemounteten Dateisystems. Immer nur einer, es sei denn das Dateisystem erlaubt explizit die Cluster Nutzung.

Wenn du das ausprobieren willst, fang mit was kleinem an. Und dann musst du dich eben mal durchknabbern bei dem Dings - https://wiki.archlinux.org/title/Open-iSCSI

Gleiches Problem hast du auch bei Hibernate/Suspend/Resume, da geht das OS auch davon aus, daß Dateisysteme zwischen Suspend und Resume nicht verändert werden. Passiert das doch dann ist womöglich auf einmal was korrupt.

Es gibt auch SD-Kartenleser, bei denen man die eingelegte SD-Karte einfach so tauschen kann - ohne daß das System überhaupt was davon mitbekommt. Und auf einmal sind nur noch korrupte Daten auf dem Laufwerk, weil das System eben noch das alte Dateisystem von der alten Karte drauf benutzt hat und die neue Karte da gar nicht dazu passt und dann eben, falsche Daten liest und schreibt. Da darf man die Karte nicht wechseln ohne das vorher ordentlich auszuwerfen.