Difference between revisions of "Fedora ARM Secondary Architecture/iSCSI"
Chris Tyler (talk | contribs) (→Kernel) |
Chris Tyler (talk | contribs) (→Goal) |
||
(8 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
− | = | + | [[Category:Fedora ARM Secondary Architecture]][[Category:Winter 2010 SBR600]] |
+ | = 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. | ||
= Kernel = | = Kernel = | ||
Line 18: | Line 21: | ||
= Results = | = Results = | ||
− | iSCSI seems to work, but only to a point | + | 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 <code>/proc/cpu/alignment</code> value of 3 (fixup+warn) did not clear the issue. | ||
+ | ** Using the exact same target with a F12 x86_64 initiator is successful. |
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:
- Kernel sources: the upstream kernel does not have OpenRD-Client support (though it does support the OpenRD-Base). Patched source obtained from git://repo.or.cz/linux-2.6/linux-2.6-openrd.git -- see discussion at http://groups.google.com/group/openrd/browse_thread/thread/6ec7b4b39700e114
- Cross-compiled on CDOT workstation HongKong using the AM cross-development toolchain available at http://fedora-arm.wantstofly.org/cross/
- Config file used: http://hongkong/chris/openrd-iscsi-kernel/openrd-iscsi-kernel-2.6.33-rc8.config.txt
Results:
- Kernel: http://hongkong/chris/openrd-iscsi-kernel/uImage-2.6.33-rc8
- Modules: http://hongkong/chris/openrd-iscsi-kernel/modules-2.6.33-rc8.tgz
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.
- Experimenting with a