Merged scripts directory from ibmvstgt-port branch (svn merge -r2369:2654 https://scst.svn.sourceforge.net/svnroot/scst/branches/ibmvstgt-port/scripts).

git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@2661 d57e44dd-8a1f-0410-8b47-8ef2f437770f
This commit is contained in:
Bart Van Assche
2010-11-11 09:26:44 +00:00
parent 17d6ca9cea
commit 1f2cedce37

View File

@@ -395,9 +395,9 @@ done \
add_file "fcst/Makefile_in-tree" \
"drivers/scst/fcst/Makefile"
add_file "fcst/Kconfig" "drivers/scst/fcst/Kconfig"
for f in $(ls fcst/*.[ch] 2>/dev/null)
do
add_file "${f}" "drivers/scst/fcst/${f#fcst/}"
@@ -556,26 +556,95 @@ fi
cat <<EOF
[SCSI] ibmvstgt: Port from tgt to SCST
The current ibmvstgt and libsrp kernel modules are based on the tgt
infrastructure. Both modules need the scsi_tgt kernel module and the tgtd user
space process in order to function properly. This patch modifies the ibmvstgt
and libsrp kernel modules such that both use the SCST storage target framework
instead of tgt. Porting ibmvstgt to SCST is required for upstream acceptance
of SCST.
The ibmvstgt and libsrp kernel modules as included in the 2.6.37 kernel are
based on the tgt SCSI target framework. Both kernel modules need the scsi_tgt
kernel module and the tgtd user space process in order to function
properly. This patch modifies the ibmvstgt and libsrp kernel modules such that
both use the SCST storage target framework instead of tgt. As a result,
neither the scsi_tgt kernel module nor the tgtd user space process are any
more necessary when using the ibmvstgt driver.
This patch introduces one backwards-incompatible change, namely that the path
of the ibmvstgt sysfs attributes is modified. This change is unavoidable
because this patch dissociates ibmvstgt SRP sessions from a SCSI host instance.
because this patch dissociates ibmvstgt SRP sessions from a SCSI host
instance. Since the user space STGT driver ibmvio was the only user of
these attributes, that shouldn't be an issue.
Notes:
- ibmvstgt is the only user of libsrp.
- A 2.6.35 kernel tree with this patch applied does compile cleanly on the
systems supported by the ibmvstgt kernel module, the patch itself is checkpatch
clean and does not introduce any new sparse warnings. This patch has not been
tested in any other way however. The primary purpose of this patch is to invite
feedback about the chosen approach.
Functional changes in ibmvstgt compared to the patch posted on October 2, 2010:
- The format of a SCSI INQUIRY response is now in the format expected by AIX.
- Added support for persistent reservations.
- Increased maximum data size for a single SRP command from 128 KB to 64 MB.
- The maximum RDMA transfer size supported by a single H_COPY_RDMA call is
queried at driver initiatlization time from the open firmware tree / larger
transfers than 128 KB are now supported too.
- If DMA mapping fails while handling a READ or WRITE command, the offending
command is retried until the associated data has been transferred instead of
reporting to the ibmvscsi client that the SCSI command failed.
- Aborting a SCSI command does no longer trigger an SRP credit leak.
- VSCSI command/response queue: one element has been reserved for management
datagrams since these fall outside the SRP credit mechanism. Added a compile-
time check whether the size of this queue is a power of two.
- Fixed a race condition which in theory could have caused the VSCSI receive
queue to overflow: srp_iu_put() is now invoked before a response is sent back
to the initiator instead of after.
- The flag SRP_RSP_FLAG_SNSVALID in an SRP_RSP information unit is now only
set when a response contains sense data and not when e.g. the response status
is BUSY and no sense data is sent back to the initiator.
- In ibmvstgt_init(), get_system_info() is now invoked before registering the
sysfs attributes that export the queried values.
- Avoid that ibmvstgt_release() triggers a NULL-pointer dereference when
invoked before a client has logged in.
- The second and subsequent SRP_LOGIN received from a client does no longer
trigger a BUG_ON() in process_login().
- Moved enum iue_flags from libsrp to ibmvstgt because it is ibmvstgt-specific.
- Removed a variable that was modified but never read from ibmvstgt_rdma().
- ibmvstgt_probe(): changed the datatype of the variable "dma" from
unsigned * into const unsigned * such that a cast could be removed.
- Fixed all compiler and sparse warnings (C=2 CF=-D__CHECK_ENDIAN__).
Functional changes in libsrp compared to the patch posted on October 2, 2010:
- Renamed vscsis_data_length() into srp_data_length() and exported
this function.
- All error messages reported via printk() do now have prefix KERN_ERR.
- modified srp_target_alloc() and srp_target_free() such that the
driver-private data reflects whether or not target data has been allocated.
This change was necessary to avoid that ibmvstgt_remove() triggers a
NULL-pointer dereference if ibmvstgt_probe() failed.
- srp_transfer_data(): All three return statements related to DMA mapping
failure do now return -ENOMEM instead of 0, -EIO and -ENOMEM.
- srp_direct_data(): Removed the ext_desc argument since not used.
- srp_direct_data() and srp_indirect_data(): Use the data length from
the SCSI CDB instead of the length from the SRP_CMD data descriptors. Also,
compute the correct data length even if dma_map == 0.
- srp_direct_data() and srp_indirect_data(): Use DMA_TO/FROM_DEVICE
instead of DMA_BIDIRECTIONAL for the buffers mapped for transferring data
via DMA.
- struct srp_target: eliminated the information unit linked list and also the
V_FLYING flag since both were duplicating information managed by the SCST
core.
- Fixed all compiler and sparse warnings (C=2 CF=-D__CHECK_ENDIAN__).
Note: ibmvstgt is the only user of libsrp.
Tests performed on a backport to kernel version 2.6.18 of this driver:
- Verified that the kernel module ibmvstgt loads and initializes successfully
and also that the client connected after loading.
- Verified that virtual disks configured in scst_vdisk were discovered by
the client.
- Performed IO stress testing on the device.
- Performed basic I/O performance testing. With a RAM disk as target linear
direct I/O throughput was above 2 GB/s and a 4 KB random I/O test resulted
in more than 10000 IOPS (without any caching of DMA mappings in the target).
Both initiator and target were a dual core POWER6 LPAR.
- Verified that after unloading and reloading ibmvstgt and after client
recovery that the initiator devices were functioning normally.
- Verified that after a client reboot ibmvscsic reconnected with the target
and that the target devices were again usable.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Cc: Fujita Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Brian King <brking@linux.vnet.ibm.com>
Cc: Robert Jennings <rcj@linux.vnet.ibm.com>
EOF
fi