Differences

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

Link to this comparison view

Both sides previous revision Previous revision
sanboot:ubuntu_iscsi [2010/08/16 20:51]
cinquero
sanboot:ubuntu_iscsi [2010/08/16 20:55]
cinquero
Line 228: Line 228:
 </​code>​ </​code>​
  
-=== Stabilization/​Paranoia ===+=== Stabilization/​Paranoia/​Warnings ​===
  
 in order to prevent data loss (for example, a corrupted dpkg db), one may do the following stuff: in order to prevent data loss (for example, a corrupted dpkg db), one may do the following stuff:
  
   * Enable data journaling. That will cut your maximum write performance in half.   * Enable data journaling. That will cut your maximum write performance in half.
-  * 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 a 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.+  * 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 a 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. 
 +  * Additional warning: ​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.

Navigation

* [[:start|Home]] * [[:about|About our Project]] * [[:download|Download]] * [[:screenshots|Screenshots]] * Documentation * [[:howtos|HowTo Guides]] * [[:appnotes|Application Notes]] * [[:faq:|FAQs]] * [[:doc|General Doc]] * [[:talks|Videos, Talks, and Papers]] * [[:hardwareissues|Hardware Issues]] * [[:mailinglists|Mailing lists]] * [[http://support.etherboot.org/|Bugtracker]] * [[:contributing|Contributing]] * [[:editing_permission|Wiki Edit Permission]] * [[:wiki:syntax|Wiki Syntax]] * [[:contact|Contact]] * [[:relatedlinks|Related Links]] * [[:commerciallinks|Commercial Links]] * [[:acknowledgements|Acknowledgements]] * [[:logos|Logo Art]]

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