Difference between revisions of "Fedora ARM Secondary Architecture/iSCSI"

From CDOT Wiki
Jump to: navigation, search
(Goal)
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
 
[[Category:Fedora ARM Secondary Architecture]][[Category:Winter 2010 SBR600]]
 
[[Category:Fedora ARM Secondary Architecture]][[Category:Winter 2010 SBR600]]
 
 
= Goal =
 
= Goal =
  
 
iSCSI is SCSI (Small Computer System Interface) block device support over Internet (TCP/IP). It's basically a way of doing a storage area network (SAN) using $20/port gigabit ethernet instead of $3000/port FibreChannel connections.
 
iSCSI is SCSI (Small Computer System Interface) block device support over Internet (TCP/IP). It's basically a way of doing a storage area network (SAN) using $20/port gigabit ethernet instead of $3000/port FibreChannel connections.
  
This may be a useful technology for providing storage to the [[Fedora ARM Secondary Architecture/ARM Hardware|ARM hardware]] devices in the build farm without attaching eSATA disks to each machine. The goal, then, was to determine if iSCSI was suitable for this application.
+
This may be a useful technology for providing storage to the [[Fedora ARM Secondary Architecture/ARM hardware|ARM hardware]] devices in the build farm without attaching eSATA disks to each machine. The goal, then, was to determine if iSCSI was suitable for this application.
  
 
= Kernel =
 
= Kernel =

Latest revision as of 15:40, 17 April 2010

Goal

iSCSI is SCSI (Small Computer System Interface) block device support over Internet (TCP/IP). It's basically a way of doing a storage area network (SAN) using $20/port gigabit ethernet instead of $3000/port FibreChannel connections.

This may be a useful technology for providing storage to the ARM hardware devices in the build farm without attaching eSATA disks to each machine. The goal, then, was to determine if iSCSI was suitable for this application.

Kernel

To test iSCSI on the OpenRD-Client system, a new kernel was required, with iSCSI support built-in or in modular form:

Results:

Results

iSCSI seems to work, but only to a point:

  • We can login to an initiator (netbsd-iscsi package on HongKong x86_64).
  • However, under heavy load (first noticed when creating a mock buildroot cache), the target receives invalid opcodes, causing the connection to fail.
    • Experimenting with a /proc/cpu/alignment value of 3 (fixup+warn) did not clear the issue.
    • Using the exact same target with a F12 x86_64 initiator is successful.