Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Last revision Both sides next revision
sanboot:ubuntu_iscsi [2010/08/11 12:17]
cinquero
sanboot:ubuntu_iscsi [2010/08/16 20:51]
cinquero
Line 213: Line 213:
 find /etc -name '​S*open-iscsi'​ find /etc -name '​S*open-iscsi'​
 </​code>​ </​code>​
 +  * One possibly has to repeat the previous step when upgrading/​reinstalling open-iscsi.
   * create /​etc/​init/​open-iscsi.conf:​   * create /​etc/​init/​open-iscsi.conf:​
-<pre>+<code>
 description "​Open-iSCSI"​ description "​Open-iSCSI"​
  
 start on filesystem start on filesystem
 +# no stopping!
 exec /​etc/​init.d/​open-iscsi start exec /​etc/​init.d/​open-iscsi start
-</pre>+</code>
   * Lucid detects on its own if rootfs is an iscsi target. It will prevent network shutdown on shutdown and read-only remounting of the rootfs should make sure that data gets flushed to disk.   * Lucid detects on its own if rootfs is an iscsi target. It will prevent network shutdown on shutdown and read-only remounting of the rootfs should make sure that data gets flushed to disk.
 +  * For your own convenience,​ edit the following line in /​etc/​default/​grub as shown below:
 +<​code>​
 +GRUB_CMDLINE_LINUX_DEFAULT="​ip=dhcp ISCSI_INITIATOR=<​yourInitiatorName>​ ISCSI_TARGET_NAME=<​yourTargetName>​ ISCSI_TARGET_IP=<​yourTargetIp>​ ISCSI_TARGET_PORT=3260 quiet splash"​
 +</​code>​
  
 === Stabilization/​Paranoia === === Stabilization/​Paranoia ===
Line 227: Line 233:
  
   * Enable data journaling. That will cut your maximum write performance in half.   * Enable data journaling. That will cut your maximum write performance in half.
-  * Increase ​node.session.timeo.replacement_timeout in iscsid.conf to avoid escalation of temporary connection problems to upper layers. In *my* situation it *never* makes sense to tell the ext4 driver about I/O problems because there is no fallback. It would just give me a corrupted ​filesystem.+  * One may increase ​node.session.timeo.replacement_timeout in iscsid.conf to avoid escalation of temporary connection problems to upper layers. In *my* situation it (almost) ​*never* makes sense to tell the ext4 driver about I/O problems because there is no fallback. It would just give me an unclean filesystem (not unmounted properly, like hard reset). However(!!),​ an unclean ​filesystem ​may be better than a totally screwed one: imagine your iSCSI target host crashes, looses some data that still has not been written to disk, and the client continues to use that target without doing a journal replay first... personally, I try to avoid that situation by never starting the iSCSI target automatically (removed from init scripts, starting it manually after killing the client machines...). IMHO the iSCSI protocol is a bit dumb. The target should detect a crash and refuse session continuation after restart... again, I'm not liable for *any* sort of data loss if you act according to these explanations. You *will* screw your data. Sooner or later. Especially because SAN boot using gpxe seems to not allow using a MaxSessions=1/​MaxConnections=1 setting for the target, which would prevent concurrent accesses -- a very basic need for data integrity purposes.

QR Code
QR Code sanboot:ubuntu_iscsi (generated for current page)