Re: [Suggestion] drivers/target/sbp/ : set tport->tpg to NULL when clean up for failure.
于 2012年12月15日 08:33, Nicholas A. Bellinger 写道: > > FYI folks, this fix from Chris was included in the [GIT PULL] request > for v3.8-rc1 sent out today. > thanks and now I am in target-de...@vger.kernel.org, too. :-) > Thanks! > > --nab > > > -- Chen Gang Asianux Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Suggestion] drivers/target/sbp/ : set tport->tpg to NULL when clean up for failure.
On Fri, 2012-12-14 at 15:22 +0800, Chen Gang wrote: > 于 2012年12月14日 14:57, Stefan Richter 写道: > > On Dec 14 Chen Gang wrote: > >> 于 2012年12月10日 16:02, Chris Boot 写道: > >>> On 10/12/12 02:39, Chen Gang wrote: > Hello Chris Boot: > > need I send the relative patch ? > >>> > >>> Hi Chen, > >>> > >>> Sorry, life got in the way this weekend. I'll try to get the patch sent > >>> out today. > >>> > >> > >> Have you sent ? > >> > >> I am already in linux-scsi@vger.kernel.org mailing list, but it seems > >> not find your patch. > > > > It was posted at target-devel: > > http://thread.gmane.org/gmane.linux.scsi.target.devel/3019/focus=3020 > > > > oh, thank you very much. > > I need join target-de...@vger.kernel.org, I will do. > FYI folks, this fix from Chris was included in the [GIT PULL] request for v3.8-rc1 sent out today. Thanks! --nab -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] target updates for v3.8-rc1
Hello Linus! Here are the target updates for v3.8-rc1 merge window code. Please go ahead and pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git for-next Just a heads up that there is a minor merge conflict that you'll encounter in target_handle_task_attr() code, that sfr has been carrying a fix for recently within -next. After dropping the HEAD section, the resolution should look like: http://git.kernel.org/?p=linux/kernel/git/nab/target-pending.git;a=commitdiff;h=50f966ab0a8630cacb46bb382cd2822a5c1448ac It has been a very busy development cycle this time around in target land, with the highlights including: - Kill struct se_subsystem_dev, in favor of direct se_device usage (hch) - Simplify reservations code by combining SPC-3 + SCSI-2 support for virtual backends only (hch) - Simplify ALUA code for virtual only backends, and remove left over abstractions (hch) - Pass sense_reason_t as return value for I/O submission path (hch) - Refactor MODE_SENSE emulation to allow for easier addition of new mode pages. (roland) - Add emulation of MODE_SELECT (roland) - Fix bug in handling of ExpStatSN wrap-around (steve) - Fix bug in TMR ABORT_TASK lookup in qla2xxx target (steve) - Add WRITE_SAME w/ UNMAP=0 support for IBLOCK backends (nab) - Convert ib_srpt to use modern target_submit_cmd caller + drop legacy ioctx->kref usage (nab) - Convert ib_srpt to use modern target_submit_tmr caller (nab) - Add link_magic for fabric allow_link destination target_items for symlinks within target_core_fabric_configfs.c code (nab) - Allocate pointers in instead of full structs for config_group->default_groups (sebastian) - Fix 32-bit highmem breakage for FILEIO (sebastian) All told, hch was able to shave off another ~1K LOC by killing the se_subsystem_dev abstraction, along with a number of PR + ALUA simplifications. Also, a nice patch by Roland is the refactoring of MODE_SENSE handling, along with the addition of initial MODE_SELECT emulation support for virtual backends. Sebastian found a long-standing issue wrt to allocation of full config_group instead of pointers for config_group->default_group[] setup in a number of areas, which ends up saving memory with big configurations. He also managed to fix another long-standing BUG wrt to broken 32-bit highmem support within the FILEIO backend driver. Thank you again to everyone who contributed this round! --nab Andy Grover (1): target/iscsi_target: Add NodeACL tags for initiator group support Chris Boot (2): sbp-target: use simple assignment in tgt_agent_rw_agent_state() sbp-target: fix error path in sbp_make_tpg() Christoph Hellwig (11): target: kill struct se_subsystem_dev target: rename spc_ops target: move REPORT LUNS emulation to target_core_spc.c target/pscsi: call spc_emulate_report_luns directly target: provide generic sbc device type/revision helpers pscsi: fix REPORT LUNS handling target: kill dev->dev_task_attr_type target: simplify reservations code target: simplify alua support target: remove ->get_device_rev target: pass sense_reason as a return value Dan Carpenter (1): target: update error handling for sbc_setup_write_same() Fengguang Wu (1): target/pscsi: Make pscsi_configure_device + target_release_session static Kees Cook (1): sbp-target: remove depends on CONFIG_EXPERIMENTAL Nicholas Bellinger (14): target: Fix incorrect starting offset after MODE_SENSE refactoring target: Fix incorrect inversion of TPGS_EXPLICT_ALUA check target: Fix possible TFO->write_pending() sense_reason_t silent WRITE corruption target: Fix exception path pr_reg put regression for PR RELEASE target: Change sbc_emulate_noop to return sense_reason_t target/sbc: Seperate WRITE_SAME based on UNMAP flag in sbc_ops target: Add/check max_write_same_len device attribute + update block limits VPD target/iblock: Add WRITE_SAME w/ UNMAP=0 emulation support target: Update copyright information to 2012 target/iblock: Forward declare bio helpers target: Make spc_get_write_same_sectors return sector_t ib_srpt: Convert I/O path to target_submit_cmd + drop legacy ioctx->kref ib_srpt: Convert TMR path to target_submit_tmr target: Add link_magic for fabric allow_link destination target_items Roland Dreier (8): iscsi-target: Use list_first_entry() where appropriate target: Refactor MODE SENSE emulation target: Implement mode page 0x1c, "Informational Exceptions" target: Add emulation for MODE SELECT iscsi-target: Fix potential deadlock on lock taken in timer iscsi-target: Always send a response before terminating iSCSI connection target: Clean up logic in transport_put_cmd() target: Clean up flow in transport_check_aborted_status() Sachin Kamat (1): iscsi_target: Remove redundant null check before kfree Sebastian Andrzej Siewior (6): target/configfs: allocate pointers instead of full struct for default_groups target/c
FCoE Updates for 3.8 (v2)
The following changes since commit b69f0859dc8e633c5d8c06845811588fe17e68b3: Linux 3.7-rc8 (2012-12-03 11:22:37 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rwlove/fcoe.git tags/for-next-12-14-12 for you to fetch changes up to 4f670ff8eb4cb3e9e6ae0c0c6976faa0a4503751: debris left by "[SCSI] libfcoe: Remove mutex_trylock/restart_syscall checks" (2012-12-14 10:38:56 -0800) FCoE Updates for 3.8 (v2) Al Viro (1): debris left by "[SCSI] libfcoe: Remove mutex_trylock/restart_syscall checks" Robert Love (7): Documentation: Add missing devices/ to devices path libfcoe: Save some memory and optimize name lookups libfcoe: Add fcoe_sysfs debug logging level libfcoe, fcoe, bnx2fc: Add new fcoe control interface fcoe: Use the fcoe_sysfs control interface bnx2fc: Use the fcoe_sysfs control interface libfc, libfcoe, fcoe: Convert debug_logging macros to pr_info Vasu Dev (1): libfc: fix REC handling Yi Zou (7): fcoe: prep work to start consolidate the usage of fcoe_netdev fcoe: add support to the get_netdev() for fcoe_interface libfcoe, fcoe: move fcoe_link_speed_update() to libfcoe and export it libfcoe, fcoe: consolidate the fcoe_ctlr_get_lesb/fcoe_get_lesb bnx2fc: add support to get_netdev for bnx2f_interface bnx2fc: use fcoe_link_speed_update() from the exported symbol in libfcoe bnx2fc: use fcoe_get_lesb/fcoe_ctlr_get_lesb() directly from libfcoe Documentation/ABI/testing/sysfs-bus-fcoe | 45 +- drivers/scsi/bnx2fc/bnx2fc_fcoe.c| 256 +- drivers/scsi/fcoe/fcoe.c | 212 +++-- drivers/scsi/fcoe/fcoe.h |6 +- drivers/scsi/fcoe/fcoe_ctlr.c| 17 +- drivers/scsi/fcoe/fcoe_sysfs.c | 186 ++ drivers/scsi/fcoe/fcoe_transport.c | 199 ++- drivers/scsi/fcoe/libfcoe.h | 20 ++- drivers/scsi/libfc/fc_fcp.c |6 +- drivers/scsi/libfc/fc_libfc.h| 38 ++--- include/scsi/fcoe_sysfs.h| 11 +- include/scsi/libfcoe.h | 32 +++- 12 files changed, 749 insertions(+), 279 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: FCoE Updates for 3.8
On Wed 12 Dec 2012 04:45:50 PM PST, Robert Love wrote:
> The following changes since commit b69f0859dc8e633c5d8c06845811588fe17e68b3:
>
>Linux 3.7-rc8 (2012-12-03 11:22:37 -0800)
>
> are available in the git repository at:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/rwlove/fcoe.git
> for-next-12-12-12
>
> for you to fetch changes up to 04f0ac991b5dd2a32c3fa3dcb2cf34830949afa5:
>
>debris left by "[SCSI] libfcoe: Remove mutex_trylock/restart_syscall
> checks" (2012-12-11 10:22:36 -0800)
>
>
> Al Viro (1):
>debris left by "[SCSI] libfcoe: Remove mutex_trylock/restart_syscall
> checks"
>
> Robert Love (7):
>Documentation: Add missing devices/ to devices path
>libfcoe: Save some memory and optimize name lookups
>libfcoe: Add fcoe_sysfs debug logging level
>libfcoe, fcoe, bnx2fc: Add new fcoe control interface
>fcoe: Use the fcoe_sysfs control interface
>bnx2fc: Use the fcoe_sysfs control interface
>libfc, libfcoe, fcoe: Convert debug_logging macros to pr_info
>
> Vasu Dev (1):
>libfc: fix REC handling
>
> Yi Zou (7):
>fcoe: prep work to start consolidate the usage of fcoe_netdev
>fcoe: add support to the get_netdev() for fcoe_interface
>libfcoe, fcoe: move fcoe_link_speed_update() to libfcoe and export it
>libfcoe, fcoe: consolidate the fcoe_ctlr_get_lesb/fcoe_get_lesb
>bnx2fc: add support to get_netdev for bnx2f_interface
>bnx2fc: use fcoe_link_speed_update() from the exported symbol in
> libfcoe
>bnx2fc: use fcoe_get_lesb/fcoe_ctlr_get_lesb() directly from libfcoe
>
> Documentation/ABI/testing/sysfs-bus-fcoe | 45 +-
> drivers/scsi/bnx2fc/bnx2fc_fcoe.c| 256
> +-
> drivers/scsi/fcoe/fcoe.c | 212 +++--
> drivers/scsi/fcoe/fcoe.h |6 +-
> drivers/scsi/fcoe/fcoe_ctlr.c| 17 +-
> drivers/scsi/fcoe/fcoe_sysfs.c | 186 ++
> drivers/scsi/fcoe/fcoe_transport.c | 199 ++-
> drivers/scsi/fcoe/libfcoe.h | 20 ++-
> drivers/scsi/libfc/fc_fcp.c |6 +-
> drivers/scsi/libfc/fc_libfc.h| 38 ++---
> include/scsi/fcoe_sysfs.h| 11 +-
> include/scsi/libfcoe.h | 32 +++-
> 12 files changed, 749 insertions(+), 279 deletions(-)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Please ignore this request. A new (v2) pull request is coming that
addresses Bart's feedback on one patch.
Thanks, //Rob
N�r��yb�X��ǧv�^�){.n�+{���"�{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj"��!�i
[PATCH v2] libfcoe: Save some memory and optimize name lookups
Instead of creating a structure with an enum and a pointer
to a string, simply allocate an array of strings and use
the enum values for the indicies.
This means that we do not need to iterate through the list
of entries when looking up a string name by its enum key.
This will also help with a latter patch that will add
more fcoe_sysfs attributes that will also use the
fcoe_enum_name_search macro. One attribute will also do
a reverse lookup which requires less code when the
enum-to-string mappings are organized as this patch makes
them to be.
Signed-off-by: Robert Love
Acked-by: Neil Horman
---
drivers/scsi/fcoe/fcoe_sysfs.c | 44 +++-
1 file changed, 16 insertions(+), 28 deletions(-)
diff --git a/drivers/scsi/fcoe/fcoe_sysfs.c b/drivers/scsi/fcoe/fcoe_sysfs.c
index 5e75168..e6fce28 100644
--- a/drivers/scsi/fcoe/fcoe_sysfs.c
+++ b/drivers/scsi/fcoe/fcoe_sysfs.c
@@ -210,25 +210,23 @@ static ssize_t show_fcoe_fcf_device_##field(struct device
*dev, \
#define fcoe_enum_name_search(title, table_type, table)
\
static const char *get_fcoe_##title##_name(enum table_type table_key) \
{ \
- int i; \
- char *name = NULL; \
- \
- for (i = 0; i < ARRAY_SIZE(table); i++) { \
- if (table[i].value == table_key) { \
- name = table[i].name; \
- break; \
- } \
- } \
- return name;\
+ if (table_key < 0 || table_key >= ARRAY_SIZE(table))\
+ return NULL;\
+ return table[table_key];\
}
-static struct {
- enum fcf_state value;
- char *name;
-} fcf_state_names[] = {
- { FCOE_FCF_STATE_UNKNOWN, "Unknown" },
- { FCOE_FCF_STATE_DISCONNECTED, "Disconnected" },
- { FCOE_FCF_STATE_CONNECTED,"Connected" },
+static char *fip_conn_type_names[] = {
+ [ FIP_CONN_TYPE_UNKNOWN ] = "Unknown",
+ [ FIP_CONN_TYPE_FABRIC ] = "Fabric",
+ [ FIP_CONN_TYPE_VN2VN ] = "VN2VN",
+};
+fcoe_enum_name_search(ctlr_mode, fip_conn_type, fip_conn_type_names)
+#define FCOE_CTLR_MODE_MAX_NAMELEN 50
+
+static char *fcf_state_names[] = {
+ [ FCOE_FCF_STATE_UNKNOWN ] = "Unknown",
+ [ FCOE_FCF_STATE_DISCONNECTED ] = "Disconnected",
+ [ FCOE_FCF_STATE_CONNECTED ]= "Connected",
};
fcoe_enum_name_search(fcf_state, fcf_state, fcf_state_names)
#define FCOE_FCF_STATE_MAX_NAMELEN 50
@@ -246,17 +244,7 @@ static ssize_t show_fcf_state(struct device *dev,
}
static FCOE_DEVICE_ATTR(fcf, state, S_IRUGO, show_fcf_state, NULL);
-static struct {
- enum fip_conn_type value;
- char *name;
-} fip_conn_type_names[] = {
- { FIP_CONN_TYPE_UNKNOWN, "Unknown" },
- { FIP_CONN_TYPE_FABRIC, "Fabric" },
- { FIP_CONN_TYPE_VN2VN, "VN2VN" },
-};
-fcoe_enum_name_search(ctlr_mode, fip_conn_type, fip_conn_type_names)
-#define FCOE_CTLR_MODE_MAX_NAMELEN 50
-
+#define FCOE_MAX_MODENAME_LEN 20
static ssize_t show_ctlr_mode(struct device *dev,
struct device_attribute *attr,
char *buf)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SCSI mid layer and high IOPS capable devices
On Fri, Dec 14, 2012 at 08:28:56PM +0100, Bart Van Assche wrote: > On 12/14/12 20:55, scame...@beardog.cce.hp.com wrote: > >It's not so much that they are re-ordered as that there is no controlled > >ordering to begin with because multiple cpus are submitting to multiple > >hardware queues concurrently. If you have 12 requests coming in on 12 > >cpus to 12 hardware queues to the device, it's going to be racy as to > >which request is processed first by the device -- and this is fine, the > >hardware queues are independent of one another and do not need to worry > >about each other. This is all to provide a means of getting enough > >commands > >on the device to actually keep it busy. A single cpu can't do it, the > >device is too fast. If you have ordering dependencies such that request > >A must complete before request B completes, then don't submit A and B > >concurrently, because if you do submit them concurrently, you cannot tell > >whether A or B will arrive into the device first because they may go into > >it via different hardware queues. > > It depends on how these multiple queues are used. If each queue would > e.g. be associated with a disjoint LBA range of the storage device then > there wouldn't be a risk of request reordering due to using multiple > hardware queues. They are not associated with disjoint LBA ranges. They are associated with CPUs on the submission side, there's a submit queue per cpu, and msix vectors on the completion side (also a completion queue per cpu). The point of the queues is only to provide a wide enough highway to allow enough requests to be shoved down to the device fast enough and completed back to the host fast enough that the device can be kept reasonably busy, instead of being starved for work to do. There is no distinction about what the requests may do based on what hardware i/o queue they come in on (e.g. no lba range partitioning). All the i/o queues are equivalent. Pretty much all current storage devices, disk drives and the devices I'm talking about in particular do depend on the low level driver and storage devices being permitted to re-order requests. So I don't think the discussion about drivers and devices that *do not* reorder requests (which drivers and devices would those be?) is very related to the topic of how to get the scsi mid layer to provide a wide enough highway for requests destined for very low latency devices. -- steve -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SCSI mid layer and high IOPS capable devices
On 12/14/12 20:55, scame...@beardog.cce.hp.com wrote: It's not so much that they are re-ordered as that there is no controlled ordering to begin with because multiple cpus are submitting to multiple hardware queues concurrently. If you have 12 requests coming in on 12 cpus to 12 hardware queues to the device, it's going to be racy as to which request is processed first by the device -- and this is fine, the hardware queues are independent of one another and do not need to worry about each other. This is all to provide a means of getting enough commands on the device to actually keep it busy. A single cpu can't do it, the device is too fast. If you have ordering dependencies such that request A must complete before request B completes, then don't submit A and B concurrently, because if you do submit them concurrently, you cannot tell whether A or B will arrive into the device first because they may go into it via different hardware queues. It depends on how these multiple queues are used. If each queue would e.g. be associated with a disjoint LBA range of the storage device then there wouldn't be a risk of request reordering due to using multiple hardware queues. Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SCSI mid layer and high IOPS capable devices
On Fri, Dec 14, 2012 at 05:15:37PM +0100, Bart Van Assche wrote: > On 12/14/12 17:44, scame...@beardog.cce.hp.com wrote: > >I expect the flash devices re-order requests as well, simply because > >to feed requests to the things at a sufficient rate, you have to pump > >requests into them concurrently on multiple hardware queues -- a single > >cpu jamming requests into them as fast as it can is still not fast enough > >to keep them busy. Consequently, they *can't* care about ordering, as the > >relative order requests on different hardware queues are submitted into > >them > >is not even really controlled, so the OS *can't* count on concurrent > >requests > >not to be essentially "re-ordered", just because of the nature of the way > >requests get into the device. > > Why should a flash device have to reorder write requests ? These devices > typically use a log-structured file system internally. It's not so much that they are re-ordered as that there is no controlled ordering to begin with because multiple cpus are submitting to multiple hardware queues concurrently. If you have 12 requests coming in on 12 cpus to 12 hardware queues to the device, it's going to be racy as to which request is processed first by the device -- and this is fine, the hardware queues are independent of one another and do not need to worry about each other. This is all to provide a means of getting enough commands on the device to actually keep it busy. A single cpu can't do it, the device is too fast. If you have ordering dependencies such that request A must complete before request B completes, then don't submit A and B concurrently, because if you do submit them concurrently, you cannot tell whether A or B will arrive into the device first because they may go into it via different hardware queues. Note, in case it isn't obvious, the hardware queues I'm talking about here are not the struct scsi_device, sdev->request_queue queues, they are typically ring buffers in host memory from which the device DMAs commands/responses to/from depending on if it's a submit queue or a completion queue and with producer/consumer indexes one of which is in host memory and one of which is a register on the device (which is which depends on the direction of the queue, from device (pi = host memory, ci = device register), or to device (pi = device register, ci = host memory)) -- steve -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/16] libfcoe: Save some memory and optimize name lookups
On Wed 12 Dec 2012 11:54:10 PM PST, Bart Van Assche wrote:
> On 12/13/12 00:22, Robert Love wrote:
>> @@ -210,25 +210,23 @@ static ssize_t
>> show_fcoe_fcf_device_##field(struct device *dev,\
>> #define fcoe_enum_name_search(title, table_type, table)\
>> static const char *get_fcoe_##title##_name(enum table_type
>> table_key)\
>> {\
>> -int i;\
>> -char *name = NULL;\
>> -\
>> -for (i = 0; i < ARRAY_SIZE(table); i++) {\
>> -if (table[i].value == table_key) {\
>> -name = table[i].name;\
>> -break;\
>> -}\
>> -}\
>> -return name;\
>> +if (table_key >= ARRAY_SIZE(table))\
>> +return NULL;\
>> +return table[table_key];\
>> }
>
> The old code was safe if table_key < 0 but the new code not. Can
> table_key be negative ?
>
>> +static char *fip_conn_type_names[] = {
>> +[ FIP_CONN_TYPE_UNKNOWN ] = "Unknown",
>> +[ FIP_CONN_TYPE_FABRIC ] = "Fabric",
>> +[ FIP_CONN_TYPE_VN2VN ] = "VN2VN",
>> +};
>
> A minor nit: indentation style is inconsistent here. Two elements are
> indented with a tab and another with eight spaces.
>
> Bart.
Thanks for the review and comments, Bart. I agree with both of your
points. I'll send an updated patch shortly. //Rob
Re: qla2xxx firmware
On Fri, 14 Dec 2012, Xose Vazquez Perez wrote: On 12/07/2012 08:05 PM, Xose Vazquez Perez wrote: please qlogic guys, send latest fw to upstream linux-firmware.git linux-firmware brings old releases: File: ql2400_fw.bin Version: 5.06.05 MID File: ql2500_fw.bin Version: 5.06.05 MIDQ qlogic-ftp releases: ql2400_fw.bin -- 5.08.00 MID ql2500_fw.bin -- 5.08.00 MIDQ btw, these URIs should be fixed: qla2xxx/Kconfig:ftp://ftp.qlogic.com/outgoing/linux/firmware/ qla2xxx/qla_init.c:#define QLA_FW_URL "ftp://ftp.qlogic.com/outgoing/linux/firmware/"; because ftp.qlogic.com is going to disappear, as stated in: ftp://ftp.qlogic.com/IMPORTANT.THIS.FTP.SITE.TO.BE.SHUTDOWN ---cut--- QLogic Corporation FTP service - Access is monitored =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - IMPORTANT NOTICE - QLogic Corporation will be shutting down this public ftp site by end of calendar year 2012. All users must transition to our replacement service as follows: QLogic Customers: Driver downloads are available at http://driverdownloads.qlogic.com QLogic Business Partners: Please contact your QLogic counterpart for assistance. QLogic Employees: Please use the new Secure File Transfer service as described in the following link. http://helpdesk.qlogic.com/AddSolution.do?solID=19288 Please Contact ftp.h...@qlogic.com for further assistance =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ---end--- Hi Xose, Thanks for the heads up. We have a patch pending (but no submitted yet) that will fix the FTP URIs. We will also be send a pull request to update the firmware soon. Thanks, Chad This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qla2xxx firmware
On 12/07/2012 08:05 PM, Xose Vazquez Perez wrote: > please qlogic guys, send latest fw to upstream linux-firmware.git > > > linux-firmware brings old releases: > File: ql2400_fw.bin > Version: 5.06.05 MID > File: ql2500_fw.bin > Version: 5.06.05 MIDQ > > qlogic-ftp releases: > ql2400_fw.bin -- 5.08.00 MID > ql2500_fw.bin -- 5.08.00 MIDQ btw, these URIs should be fixed: qla2xxx/Kconfig:ftp://ftp.qlogic.com/outgoing/linux/firmware/ qla2xxx/qla_init.c:#define QLA_FW_URL "ftp://ftp.qlogic.com/outgoing/linux/firmware/"; because ftp.qlogic.com is going to disappear, as stated in: ftp://ftp.qlogic.com/IMPORTANT.THIS.FTP.SITE.TO.BE.SHUTDOWN ---cut--- QLogic Corporation FTP service - Access is monitored =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - IMPORTANT NOTICE - QLogic Corporation will be shutting down this public ftp site by end of calendar year 2012. All users must transition to our replacement service as follows: QLogic Customers: Driver downloads are available at http://driverdownloads.qlogic.com QLogic Business Partners: Please contact your QLogic counterpart for assistance. QLogic Employees: Please use the new Secure File Transfer service as described in the following link. http://helpdesk.qlogic.com/AddSolution.do?solID=19288 Please Contact ftp.h...@qlogic.com for further assistance =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ---end--- -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SCSI mid layer and high IOPS capable devices
On 12/14/12 17:44, scame...@beardog.cce.hp.com wrote: I expect the flash devices re-order requests as well, simply because to feed requests to the things at a sufficient rate, you have to pump requests into them concurrently on multiple hardware queues -- a single cpu jamming requests into them as fast as it can is still not fast enough to keep them busy. Consequently, they *can't* care about ordering, as the relative order requests on different hardware queues are submitted into them is not even really controlled, so the OS *can't* count on concurrent requests not to be essentially "re-ordered", just because of the nature of the way requests get into the device. Why should a flash device have to reorder write requests ? These devices typically use a log-structured file system internally. Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch,v3,repost 00/10] make I/O path allocations more numa-friendly
James Bottomley writes: > On Mon, 2012-12-10 at 12:59 -0500, Jeff Moyer wrote: >> Jeff Moyer writes: >> >> > Hi, >> > >> > This patch set makes memory allocations for data structures used in >> > the I/O path more numa friendly by allocating them from the same numa >> > node as the storage device. I've only converted a handful of drivers >> > at this point. My testing is limited by the hardware I have on hand. >> > Using these patches, I was able to max out the bandwidth of the storage >> > controller when issuing I/O from any node on my 4 node system. Without >> > the patch, I/O from nodes remote to the storage device would suffer a >> > penalty ranging from 6-12%. Given my relatively low-end setup[1], I >> > wouldn't be surprised if others could show a more significant performance >> > advantage. >> > >> > This is a repost of the last posting. The only changes are additional >> > reviewed-by/acked-by tags. I think this version is ready for inclusion. >> > James, would you mind taking a look? >> >> James? Do you have any objections to including this for 3.8? > > Probably for 3.9 since the 3.8 merge window is upon us. OK. > Do we actually have any performance numbers from the big system people? > That's really a must for this type of work. I'm working on getting some numbers. > It's missing acks from the affected drivers; that's not a show stopper > but it would be better to have them. Well, we could trim the driver list to those that have ACKs, but the driver changes are trivial. Thanks, Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SCSI mid layer and high IOPS capable devices
On Fri, Dec 14, 2012 at 10:44:34AM +0100, Bart Van Assche wrote: > On 12/13/12 17:49, Christoph Hellwig wrote: > >On Thu, Dec 13, 2012 at 05:47:14PM +0100, Bart Van Assche wrote: > >> From my experience with block and SCSI drivers option (1) doesn't > >>look attractive from a performance point of view. From what I have > >>seen performance with QD=1 is several times lower than performance > >>with QD > 1. But maybe I overlooked something ? > > > >What you might be missing is that at least on Linux no one who cares > >about performance uses the Posix AIO inferface anyway, as the > >implementation in glibc always has been horrible. The Linux-native > >aio interface or the various thread pool implementations don't imply > >useless ordering and thus can be used to fill up large queues. > > Some applications need write ordering without having a need for > enforcing durability as fsync() does [1]. What I'm wondering about is > whether an operating system kernel like the Linux kernel should penalize > application performance when using block drivers and storage hardware > that preserve the order of write requests because there exist other > drivers and storage devices that do not preserve the order of write > requests ? Which devices don't re-order requests? So far as I know every single disk drive ever made that is capable of handling multiple requests will also re-order requests as it sees fit. I expect the flash devices re-order requests as well, simply because to feed requests to the things at a sufficient rate, you have to pump requests into them concurrently on multiple hardware queues -- a single cpu jamming requests into them as fast as it can is still not fast enough to keep them busy. Consequently, they *can't* care about ordering, as the relative order requests on different hardware queues are submitted into them is not even really controlled, so the OS *can't* count on concurrent requests not to be essentially "re-ordered", just because of the nature of the way requests get into the device. So I think the property that devices and drivers are free to reorder concurrent requests is not going away. -- steve -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SCSI mid layer and high IOPS capable devices
On 12/13/12 17:49, Christoph Hellwig wrote: On Thu, Dec 13, 2012 at 05:47:14PM +0100, Bart Van Assche wrote: From my experience with block and SCSI drivers option (1) doesn't look attractive from a performance point of view. From what I have seen performance with QD=1 is several times lower than performance with QD > 1. But maybe I overlooked something ? What you might be missing is that at least on Linux no one who cares about performance uses the Posix AIO inferface anyway, as the implementation in glibc always has been horrible. The Linux-native aio interface or the various thread pool implementations don't imply useless ordering and thus can be used to fill up large queues. Some applications need write ordering without having a need for enforcing durability as fsync() does [1]. What I'm wondering about is whether an operating system kernel like the Linux kernel should penalize application performance when using block drivers and storage hardware that preserve the order of write requests because there exist other drivers and storage devices that do not preserve the order of write requests ? [1] Richard Hipp, Re: [sqlite] SQLite on flash (was: [PATCH 00/16] f2fs: introduce flash-friendly file system), October 10, 2012 (http://www.mail-archive.com/sqlite-users@sqlite.org/msg73033.html). Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
