Re: [PATCH-v2 0/6] vhost/scsi: Add T10 PI SGL passthrough support
Il 08/06/2014 18:05, Michael S. Tsirkin ha scritto: OK, finally went over this, looks good to me: Acked-by: Michael S. Tsirkin m...@redhat.com However, we really should stop making more changes before fixing ANY_LAYOUT in this driver. virtio 1.0 should be out soon and that makes ANY_LAYOUT a required feature. Agreed. virtio-blk btw is getting ANY_LAYOUT support in QEMU 2.1, and virtio-scsi will follow suit. Paolo -- 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-v2 1/6] virtio-scsi.h: Add virtio_scsi_cmd_req_pi + VIRTIO_SCSI_F_T10_PI bits
On Thu, May 22, 2014 at 02:26:17AM +, Nicholas A. Bellinger wrote:
From: Nicholas Bellinger n...@linux-iscsi.org
This patch adds a virtio_scsi_cmd_req_pi header as recommened by
Paolo that contains do_pi_niov + di_pi_niov elements used for
signaling when protection information buffers are expected to
preceed the data buffers.
Also add new VIRTIO_SCSI_F_T10_PI feature bit to be used to signal
host support.
v4 changes:
- Use pi_bytesout + pi_bytesin instead of niovs (mst + paolo)
Cc: Paolo Bonzini pbonz...@redhat.com
Cc: Michael S. Tsirkin m...@redhat.com
Cc: Martin K. Petersen martin.peter...@oracle.com
Cc: Christoph Hellwig h...@lst.de
Cc: Hannes Reinecke h...@suse.de
Cc: Sagi Grimberg sa...@dev.mellanox.co.il
Cc: H. Peter Anvin h...@zytor.com
Signed-off-by: Nicholas Bellinger n...@linux-iscsi.org
---
include/linux/virtio_scsi.h | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/include/linux/virtio_scsi.h b/include/linux/virtio_scsi.h
index 4195b97..7344906 100644
--- a/include/linux/virtio_scsi.h
+++ b/include/linux/virtio_scsi.h
@@ -35,11 +35,23 @@ struct virtio_scsi_cmd_req {
u8 lun[8]; /* Logical Unit Number */
u64 tag;/* Command identifier */
u8 task_attr; /* Task attribute */
- u8 prio;
+ u8 prio;/* SAM command priority field */
u8 crn;
u8 cdb[VIRTIO_SCSI_CDB_SIZE];
} __packed;
+/* SCSI command request, followed by protection information */
+struct virtio_scsi_cmd_req_pi {
+ u8 lun[8]; /* Logical Unit Number */
+ u64 tag;/* Command identifier */
+ u8 task_attr; /* Task attribute */
+ u8 prio;/* SAM command priority field */
+ u8 crn;
+ u32 pi_bytesout;/* DataOUT PI Number of bytes */
+ u32 pi_bytesin; /* DataIN PI Number of bytes */
+ u8 cdb[VIRTIO_SCSI_CDB_SIZE];
+} __packed;
+
/* Response, followed by sense data and data-in */
struct virtio_scsi_cmd_resp {
u32 sense_len; /* Sense data length */
@@ -97,6 +109,7 @@ struct virtio_scsi_config {
#define VIRTIO_SCSI_F_INOUT0
#define VIRTIO_SCSI_F_HOTPLUG 1
#define VIRTIO_SCSI_F_CHANGE 2
+#define VIRTIO_SCSI_F_T10_PI3
I'd like to add that it's strange to add a macro and
only use it in patch 5.
I believe this is one of the reasons bug in patch 5 went
unnoticed ...
/* Response codes */
#define VIRTIO_SCSI_S_OK 0
--
1.7.10.4
--
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-v2 0/6] vhost/scsi: Add T10 PI SGL passthrough support
On Thu, May 22, 2014 at 02:26:16AM +, Nicholas A. Bellinger wrote: From: Nicholas Bellinger n...@linux-iscsi.org Hi MST, MKP, Paolo Co, Here is the v2 patch series for adding T1O protection information (PI) SGL passthrough support between virtio-scsi LLD + vhost-scsi fabric endpoints. Following MST's recommendation, it includes the changes for using bytes intead of number of iovecs in virtio_scsi_cmd_req_pi along with the associated changes to virtio-scsi + vhost/scsi code. For vhost/scsi, this includes walking the leading iovec's length(s) to determine where protection payload ends, and real data payload starts. For virtio-scsi LLD code, this includes locating struct blk_integrity for using blk_rq_sectors + -tuple_size to calculate the total bytes for outgoing cmd_pi-pi_bytes[out,in] values. The full list of changes from last series include: - Use pi_bytesout + pi_bytesin instead of niovs in virtio-scsi PI header (mst + paolo) - Add prot_pto=1 in tcm_vhost_submission_work() when no PI buffer exists (nab) - Get rid of req + cdb pointer casts in vhost_scsi_handle_vq (mst) - Ensure that virtio_scsi_cmd_req_pi processing happens regardless of data_num in vhost_scsi_handle_vq (nab) - Pass TARGET_PROT_ALL into transport_init_session_tags() (nab) - Convert vhost_scsi_handle_vq to use memcpy_fromiovecend() (mst) - Convert vhost_scsi_handle_vq to use pi_bytesout + pi_bytesin (nab) - Convert virtio_scsi_init_hdr_pi() to use pi_bytesout + pi_bytesin (mst + paolo + nab) - Use blk_integrity-tuple_size to calculate pi bytes (nab) Please review for v3.16-rc1 code. Thanks! --nab OK since this conflicts with my vhost locking patches, I have rebased this and parked at vhost-review branch in my tree. git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost-review Nicholas could you please take a look at the patches and confirm this is OK ASAP? If yes I will pack it all up and send to Linus. Nicholas Bellinger (6): virtio-scsi.h: Add virtio_scsi_cmd_req_pi + VIRTIO_SCSI_F_T10_PI bits vhost/scsi: Move sanity check into vhost_scsi_map_iov_to_sgl vhost/scsi: Add preallocation of protection SGLs vhost/scsi: Add T10 PI IOV - SGL memory mapping logic vhost/scsi: Enable T10 PI IOV - SGL memory mapping virtio-scsi: Enable DIF/DIX modes in SCSI host LLD drivers/scsi/virtio_scsi.c | 86 +--- drivers/vhost/scsi.c| 305 +-- include/linux/virtio_scsi.h | 15 ++- 3 files changed, 292 insertions(+), 114 deletions(-) -- 1.7.10.4 -- 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] First round of SCSI updates for the 3.15+ merge window
This patch consists of the usual driver updates (qla2xxx, qla4xxx, lpfc, be2iscsi, fnic, ufs, NCR5380) The NCR5380 is the addition to maintained status of a long neglected driver for older hardware. In addition there are a lot of minor fixes and cleanups and some more updates to make scsi mq ready. The patch is available here: git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-for-linus The short changelog is: Adheer Chandravanshi (2): qla4xxx: Fix smatch warning in func qla4xxx_conn_get_param qla4xxx: Fix smatch warning in func qla4xxx_get_ep_param Alexey Khoroshilov (1): bfa: allocate memory with GFP_ATOMIC in spinlock context Armen Baloyan (3): qla2xxx: Adjust adapter reset routine to the changes in firmware specification for ISPFx00. qla2xxx: Decrease pci access for response queue processing for ISPFX00. qla2xxx: Change copyright year to 2014 in all the source files. Atul Deshmukh (3): qla2xxx: IOCB data should be copied to I/O mem using memcpy_toio. qla2xxx: Include delay.h file for msleep declartion in qla_nx2.c file. qla2xxx: Use proper log message for flash lock failed error. Ben Hutchings (1): mvsas: Recognise device/subsystem 9485/9485 as 88SE9485 Benoit Taine (2): qla2xxx: Use kmemdup instead of kmalloc + memcpy qla4xxx: Use kmemdup instead of kmalloc + memcpy Chad Dupuis (7): qla2xxx: Remove wait for online from host reset handler. qla2xxx: Do logins from a chip reset in DPC thread instead of the error handler thread. qla2xxx: Reduce the time we wait for a command to complete during SCSI error handling. qla2xxx: Clear loop_id for ports that are marked lost during fabric scanning. qla2xxx: Avoid escalating the SCSI error handler if the command is not found in firmware. qla2xxx: Remove unnecessary printk_ratelimited from qla_nx2.c qla2xxx: Do not schedule reset when one is already active when receiving an invalid status handle. Christoph Hellwig (7): Revert be2iscsi: Fix processing cqe for cxn whose endpoint is freed scsi_debug: simple short transfer injection virtio_scsi: use cmd_size scsi: handle command allocation failure in scsi_reset_provider scsi: reintroduce scsi_driver.init_command scsi: remove scsi_end_request scsi: explicitly release bidi buffers Dan Carpenter (1): qla2xxx: fix incorrect debug printk David Jeffery (1): sd: medium access timeout counter fails to reset Fabian Frederick (1): include/scsi/osd_protocol.h: remove unnecessary __constant Finn Thain (14): scsi/NCR5380: dprintk macro scsi/NCR5380: merge sun3_scsi_vme.c into sun3_scsi.c scsi/NCR5380: reduce depth of sun3_scsi nested includes scsi/NCR5380: remove unused macro definitions scsi/NCR5380: fix and standardize NDEBUG macros scsi/NCR5380: adopt dprintk() scsi/NCR5380: adopt NCR5380_dprint() and NCR5380_dprint_phase() scsi/NCR5380: fix dprintk macro usage and definition scsi/NCR5380: fix build failures when debugging is enabled scsi/NCR5380: use NCR5380_dprint() instead of NCR5380_print() scsi/NCR5380: remove old CVS keywords scsi/NCR5380: remove redundant HOSTS_C macro tests scsi/NCR5380: remove unused BOARD_NORMAL and BOARD_NCR53C400 MAINTAINERS: add an entry for all the NCR5380 drivers Giridhar Malavali (3): qla2xxx: Check for peg alive counter and clear any outstanding mailbox command. qla2xxx: Issue abort command for outstanding commands during cleanup when only firmware is alive. qla2xxx: Log when device state is moved to failed state. Hannes Reinecke (1): scsi: set correct completion code in scsi_send_eh_cmnd() Himanshu Madani (1): qla2xxx: Fix beacon blink logic for ISP26xx/83xx. Himanshu Madhani (1): qla2xxx: Remove mapped vp index iterator macro dead code. Hiral Patel (5): qla2xxx: Check the QLA8044_CRB_DRV_ACTIVE_INDEX register when we are not the owner of the reset. qla2xxx: Enable fw_dump_size for ISP8044. qla2xxx: Introduce fw_dump_flag to track fw dump progress. qla2xxx: Remove unnecessary delays from fw dump code path. qla2xxx: Track the process when the ROM_LOCK failure happens Hiral Shah (3): fnic: fnic Control Path Trace Utility fnic: Failing to queue aborts due to Q full cause terminate driver timeout fnic: NoFIP solicitation frame in NONFIP mode and changed IO Throttle count James Smart (1): lpfc: Add iotag memory barrier Jayamohan Kallickal (8): be2iscsi: Bump the driver version be2iscsi: Fix processing cqe for cxn whose endpoint is freed be2iscsi: Fix destroy MCC-CQ before MCC-EQ is destroyed be2iscsi: Fix memory corruption in MBX path be2iscsi: Fix TCP parameters while connection offloading. be2iscsi: Fix interrupt Coalescing mechanism. be2iscsi: Fix exposing Host in
Re: [PATCH 0/2] tcm_fc: Generate TASK_SET_FULL for DataIN + response failures
On Fri, 2014-06-06 at 14:09 -0700, Nicholas A. Bellinger wrote: So if you don't mind I'll go ahead and queue these up for now in target-pending/for-next, given they are pretty straight-forward fixes. If they end up being problematic, they can be dropped before the v3.16 PULL request goes out next week. All make sense, so go head with the push and I already added reviewed by to both patches. //Vasu -- 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 1/2] tcm_fc: Generate TASK_SET_FULL status for DataIN failures
On Fri, 2014-06-06 at 14:02 -0700, Nicholas A. Bellinger wrote: The break aborts the DataIN send loop and invokes ft_queue_status() below in an attempt to send TASK_SET_FULL status. If the ft_queue_status() - lport-tt.seq_send() also fails, then -ENOMEM will be returned to the target and a delayed re-queue attempt will be made. I see. In any event, updating the comment above to be more precise I'm ok with leaving comment as is for now, just to avoid patch re-spin for this after above clarification. Thanks for detailed clarification //Vasu -- 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 eats error from flush failure during hot plug
Thanks a bunch James! I patched and ran our suite over the weekend and didn't see any failures at all. I also didn't notice any side effects. I poked through the kernel logs and everything looked like it did before. I'll let you know if anything else weird crops up. Any idea when this will get checked in? Steven On Sat, Jun 7, 2014 at 12:29 PM, James Bottomley james.bottom...@hansenpartnership.com wrote: On Thu, 2014-06-05 at 16:52 -0700, Steven Haber wrote: Hello, I am testing ATA device durability during hot unplug. I have a power fault test suite that has turned up issues with the fsync-SCSI-ATA codepath. If a device is unplugged while an fsync is in progress, ATA returns a flush error to the SCSI driver but scsi_io_completion() seems to disregard it. fsync() returns no error, which should mean that the write was durably flushed to disk. I expect fsync() to return EIO or something similar when the flush isn't acked by the device. When the failure occurs, the SCSI sense key is set to ABORTED_COMMAND. However, scsi_end_command() is called without any of the sense context and scsi_io_completion() returns early without checking sense at all. This commit may be related: d6b0c53723753fc0cfda63f56735b225c43e1e9a (http://git.opencores.org/?a=commitdiffp=linuxh=d6b0c53723753fc0cfda63f56735b225c43e1e9a) The following patch fixes the issue, but it's a hack. I only have a vague understanding of Linux drivers, so I'm looking for advice on how to make this fix better and get it upstream. OK, so for some reason this is a zero size REQ_TYPE_FS command, which the logic actually assumes we cannot have. I suspect REQ_TYPE_FLUSH subtly broke this logic because it's coming back to us as REQ_TYPE_FS even though it's been set up (in SCSI) as REQ_TYPE_BLOCK_PC. On this theory, we'd eat the return codes of all no data transfer commands that fail. I think the generic fix is to make sure that all commands initiallised as REQ_TYPE_BLOCK_PC actually have the -cmd_type set to that. There may be some knock on side effects because it doesn't look like the block flush code expects us to change the request-cmd_type. Cc'd Jens for opinions on this. Can you try this out and see if it fixes the problem? If it doesn't, we're going to have to get into debugging exactly what this zero length request is. Thanks, James --- diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index 9db097a..78229ec7 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -1171,6 +1171,11 @@ int scsi_setup_blk_pc_cmnd(struct scsi_device *sdev, struct request *req) cmd-transfersize = blk_rq_bytes(req); cmd-allowed = req-retries; + /* +* Thanks to flush and other PC prepared commands, we may +* not be a REQ_TYPE_BLOCK_PC; make sure we are +*/ + req-cmd_type = REQ_TYPE_BLOCK_PC; return BLKPREP_OK; } EXPORT_SYMBOL(scsi_setup_blk_pc_cmnd); -- 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: [Open-FCoE] [PATCH] fc: ensure scan_work isn't active when freeing fc_rport
On Fri, 2014-06-06 at 16:54 -0400, Neil Horman wrote: On Mon, Jun 02, 2014 at 04:22:50PM -0700, Vasu Dev wrote: On Fri, 2014-05-30 at 10:59 -0400, Neil Horman wrote: debugfs caught this: WARNING: at lib/debugobjects.c:260 debug_print_object+0x83/0xa0() ODEBUG: free active (active state 0) object type: work_struct hint: fc_scsi_scan_rport+0x0/0xd0 [scsi_transport_fc] CPU: 1 PID: 184 Comm: kworker/1:1 Tainted: GW -- 3.10.0-123.el7.x86_64.debug #1 Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013 Workqueue: fc_wq_5 fc_rport_final_delete [scsi_transport_fc] Call Trace: [8169efec] dump_stack+0x19/0x1b [8106cbd1] warn_slowpath_common+0x61/0x80 [8106cc4c] warn_slowpath_fmt+0x5c/0x80 [8133e003] debug_print_object+0x83/0xa0 [a04e2f40] ? fc_parse_wwn+0x100/0x100 [8133f23b] debug_check_no_obj_freed+0x22b/0x270 [a04e127e] ? fc_rport_dev_release+0x1e/0x30 [811db3e9] kfree+0xd9/0x2d0 [a04e127e] fc_rport_dev_release+0x1e/0x30 [81428032] device_release+0x32/0xa0 [8132701e] kobject_release+0x7e/0x1b0 [81326ed8] kobject_put+0x28/0x60 [81428397] put_device+0x17/0x20 [a04e5025] fc_rport_final_delete+0x165/0x210 [810959b0] process_one_work+0x220/0x710 [81095944] ? process_one_work+0x1b4/0x710 [81095fbb] worker_thread+0x11b/0x3a0 [81095ea0] ? process_one_work+0x710/0x710 [8109e0cd] kthread+0xed/0x100 [8109dfe0] ? insert_kthread_work+0x80/0x80 [816b2fec] ret_from_fork+0x7c/0xb0 [8109dfe0] ? insert_kthread_work+0x80/0x80 Seems to be because the scan_work work_struct might be active when the housing fc_rport struct gets freed. Ensure that we cancel it prior to freeing the rport Signed-off-by: Neil Horman nhor...@tuxdriver.com CC: linux-scsi@vger.kernel.org CC: Robert Love robert.w.l...@intel.com CC: Vasu Dev vasu@intel.com --- drivers/scsi/scsi_transport_fc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c index 4628fd5..5bd552c 100644 --- a/drivers/scsi/scsi_transport_fc.c +++ b/drivers/scsi/scsi_transport_fc.c @@ -2548,6 +2548,7 @@ fc_rport_final_delete(struct work_struct *work) fc_flush_devloss(shost); if (!cancel_delayed_work(rport-dev_loss_work)) fc_flush_devloss(shost); + cancel_work_sync(rport-scan_work); Make sense to ensure pending work canceled, adding James Smart for his ACK as transport FC class author. Reviewed-by: Vasu Dev vasu@intel.com Ping on this, Something just occured to me. I was thinking (perhaps erroneously) that this would go through the FCoE tree, but I don't see that you've setup a tree yet vasu (and Rob's has been idle for 6 months). Whats the plan for this (and future) fcoe patchs. Will you have a tree, or will we send this through Christophs new scsi tree perhaps? Thanks Neil for bringing this, I and Rob also had off list discussion on this just last week. Given fcoe is quite mature now and its patches volume is very low, so getting its kernel patches directly to scsi subsystem should work fine and should be okay with James or Christophs to pull into scsi subsystem directly once I've my non-author signoff ACK there as described in this announcement at http://marc.info/?l=linux-scsim=140050839729415w=2 If no alternate suggestion or objection to this then I'll formally announce this on fcoe mailing list. However for any huges patches series bomb or RFCs, I'll request fcoe developers to send patches against scsi tree at fcoe devel list first and then if needed I can roll them up. Thanks, Vasu -- 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: [Open-FCoE] [PATCH] fc: ensure scan_work isn't active when freeing fc_rport
On Mon, Jun 09, 2014 at 11:09:43AM -0700, Vasu Dev wrote: On Fri, 2014-06-06 at 16:54 -0400, Neil Horman wrote: On Mon, Jun 02, 2014 at 04:22:50PM -0700, Vasu Dev wrote: On Fri, 2014-05-30 at 10:59 -0400, Neil Horman wrote: debugfs caught this: WARNING: at lib/debugobjects.c:260 debug_print_object+0x83/0xa0() ODEBUG: free active (active state 0) object type: work_struct hint: fc_scsi_scan_rport+0x0/0xd0 [scsi_transport_fc] CPU: 1 PID: 184 Comm: kworker/1:1 Tainted: GW -- 3.10.0-123.el7.x86_64.debug #1 Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013 Workqueue: fc_wq_5 fc_rport_final_delete [scsi_transport_fc] Call Trace: [8169efec] dump_stack+0x19/0x1b [8106cbd1] warn_slowpath_common+0x61/0x80 [8106cc4c] warn_slowpath_fmt+0x5c/0x80 [8133e003] debug_print_object+0x83/0xa0 [a04e2f40] ? fc_parse_wwn+0x100/0x100 [8133f23b] debug_check_no_obj_freed+0x22b/0x270 [a04e127e] ? fc_rport_dev_release+0x1e/0x30 [811db3e9] kfree+0xd9/0x2d0 [a04e127e] fc_rport_dev_release+0x1e/0x30 [81428032] device_release+0x32/0xa0 [8132701e] kobject_release+0x7e/0x1b0 [81326ed8] kobject_put+0x28/0x60 [81428397] put_device+0x17/0x20 [a04e5025] fc_rport_final_delete+0x165/0x210 [810959b0] process_one_work+0x220/0x710 [81095944] ? process_one_work+0x1b4/0x710 [81095fbb] worker_thread+0x11b/0x3a0 [81095ea0] ? process_one_work+0x710/0x710 [8109e0cd] kthread+0xed/0x100 [8109dfe0] ? insert_kthread_work+0x80/0x80 [816b2fec] ret_from_fork+0x7c/0xb0 [8109dfe0] ? insert_kthread_work+0x80/0x80 Seems to be because the scan_work work_struct might be active when the housing fc_rport struct gets freed. Ensure that we cancel it prior to freeing the rport Signed-off-by: Neil Horman nhor...@tuxdriver.com CC: linux-scsi@vger.kernel.org CC: Robert Love robert.w.l...@intel.com CC: Vasu Dev vasu@intel.com --- drivers/scsi/scsi_transport_fc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c index 4628fd5..5bd552c 100644 --- a/drivers/scsi/scsi_transport_fc.c +++ b/drivers/scsi/scsi_transport_fc.c @@ -2548,6 +2548,7 @@ fc_rport_final_delete(struct work_struct *work) fc_flush_devloss(shost); if (!cancel_delayed_work(rport-dev_loss_work)) fc_flush_devloss(shost); + cancel_work_sync(rport-scan_work); Make sense to ensure pending work canceled, adding James Smart for his ACK as transport FC class author. Reviewed-by: Vasu Dev vasu@intel.com Ping on this, Something just occured to me. I was thinking (perhaps erroneously) that this would go through the FCoE tree, but I don't see that you've setup a tree yet vasu (and Rob's has been idle for 6 months). Whats the plan for this (and future) fcoe patchs. Will you have a tree, or will we send this through Christophs new scsi tree perhaps? Thanks Neil for bringing this, I and Rob also had off list discussion on this just last week. Given fcoe is quite mature now and its patches volume is very low, so getting its kernel patches directly to scsi subsystem should work fine and should be okay with James or Christophs to pull into scsi subsystem directly once I've my non-author signoff ACK there as described in this announcement at http://marc.info/?l=linux-scsim=140050839729415w=2 If no alternate suggestion or objection to this then I'll formally announce this on fcoe mailing list. However for any huges patches series bomb or RFCs, I'll request fcoe developers to send patches against scsi tree at fcoe devel list first and then if needed I can roll them up. Thanks, Vasu Copy that Vasu, Christoph, is that ok with you? Neil -- 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: [RFC Patch]: scsi: sysfs file cache_type not in sync with mode page
In order to issue a BLKRRPART the drive needs to be unmounted first, this
is not always possible on a machine. There is another way though:
'echo 1 /sys/block/sda/device/rescan'. This rescans all the mode pages
so that the kernel is in sync.
Writing to cache_type does seem to be a better idea than using sdparm, but
this is erroring out on one of our drives, whereas sdparm sets it without
an error.
$echo write through /sys/class/scsi_disk/6\:0\:0\:0/cache_type
-bash: echo: write error: Invalid argument
$dmesg | tail -4
[1667272.378024] sd 6:0:0:0: [sda]
[1667272.378547] Sense Key : Illegal Request [current]
[1667272.379254] sd 6:0:0:0: [sda]
[1667272.379758] Add. Sense: Invalid field in parameter list
I can think of a scenario where the kernel thinks that WCE is not set and issue
wrong flush commands and assume that the cache has been cleared. I think we
should find a better way to keep the kernel in sync, or inform the kernel of
this change.
- Vishwanath
On 06/06/2014 09:49 PM, Douglas Gilbert wrote:
On 14-06-06 06:55 PM, James Bottomley wrote:
On Fri, 2014-06-06 at 17:14 -0400, Pai wrote:
Hi All,
I noticed that the sysfs file cache_type is not is sync with the
information in the mode page. If we change the WCE attribute in the mode
page (sdparm --set=WCE /dev/sda and sdparm --clear=WCE /dev/sda) it does
not reflect this in the sysfs file.
$ cat /sys/block/sda/device/scsi_disk/6\:0\:0\:0/cache_type
write back
$ sdparm --clear=WCE /dev/sda
/dev/sda: TOSHIBA AL13SEB6000101
$ cat /sys/block/sda/device/scsi_disk/6\:0\:0\:0/cache_type
write back
Ideally cache_type should have changed to 'write through' or 'none'. I have
a small one line change that can fix this one. This patch applies against
the latest branch linux-3.15-rc8.
Few things to note:
1. revalidate_disk() also reads a whole bunch of other things from the mode
page and I don't know if this will have any side effects. This call is made
on store_cache_type as well, so I think it should be OK.
2. This is extra work which is not needed in most cases (mode pages hardly
change). Is there an event that we can subscribe to when the modpages
change?
Please review.
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index efcbcd1..5b65ccc 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -256,6 +256,7 @@ static ssize_t
cache_type_show(struct device *dev, struct device_attribute *attr, char
*buf)
{
struct scsi_disk *sdkp = to_scsi_disk(dev);
+ revalidate_disk(sdkp-disk);
int ct = sdkp-RCD + 2*sdkp-WCE;
return snprintf(buf, 40, %s\n, sd_cache_types[ct]);
The behaviour you describe is correct. The cache type is probed once at
init. If you change the cache behind the back of the linux code, you
have to expect that we won't see it. We're definitely not doing a
revalidate on every write just in case, so by extension we expect that
to see it via sysfs either you change it through the provided interface
(writing to the cache_type file) or you inform the kernel if you change
it via other means by issuing the BLKRRPART ioctl.
Have a look at
echo write through /sys/class/scsi_disk/6\:0\:0\:0/cache_type
and/or
echo write back /sys/class/scsi_disk/6\:0\:0\:0/cache_type
and those strings can be prefixed by temporary . The explanation
and mapping to T10 terms is in drivers/scsi/sd.c cache_type_store(),
or at least should be.
Doug Gilbert
--
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
MESSAGE FROM JAZMIN FOX FIN AID
-- Are you in need of a personal loan? or you are in need of a business loan? We offer loans from the range individual and cooperate bodies in need of financial support are application? only about 18 years for the applicant available. contact us by e-mail, though. onto a fast and easy loan interested in a low and affordable interest rate of 3% Interested applicants are required to this form below and send it back to us: Full Name: .. Consumption: . Loan Terms / Duration: ... Country: State: Occupation: .. Gender: Address: . Phone Number: We hope to hear from you soon so that we can send you the Credit Terms and repayment schedule. Be assured that the possibility of a loan from our company is extremely Guaranteed. Regards Jazmin Fox Fin Aid jazminfoxfin...@gmail.com -- 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
