On 11/06/2014 08:40 AM, Christoph Hellwig wrote:
> scsi_reset_provider already manually runs all queues for the given host,
> so it doesn't need the scsi_run_queues call from it, and it doesn't need
> a reference on the device because it's synchronous.
>
> So let's just call scsi_put_command direc
On 11/06/2014 08:40 AM, Christoph Hellwig wrote:
> There's only one caller left, so inline it and reduce the blk-mq vs !blk-mq
> diff a litte bit.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Bart Van Assche
> ---
> drivers/scsi/scsi_lib.c | 18 --
> drivers/scsi/scsi_pr
On 11/06/2014 08:40 AM, Christoph Hellwig wrote:
> scsi_lib.c is where the rest of the I/O submission path lives, so move
> scsi_dispatch_cmd there and mark it static.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Bart Van Assche
A round of applause for that.
One of the most annoying thin
On 11/06/2014 08:40 AM, Christoph Hellwig wrote:
> There is no reason for ULDs to pass in a flag on how to allocate the S/G
> lists. While we don't need GFP_ATOMIC for the blk-mq case because we
> don't hold locks, that decision can be made way down the chain without
> having to pass a pointless g
On 11/06/2014 08:40 AM, Christoph Hellwig wrote:
> Now that we are using the split completion model for the legacy request
> path as well we can use scsi_mq_free_sgtables unconditionally.
>
> Rename it to scsi_free_sgtables, use it for the legacy path and remove
> scsi_release_(bidi_)buffers.
>
>
On 11/06/2014 08:40 AM, Christoph Hellwig wrote:
> Move a bit code out of scsi_io_completion and into scsi_requeue_command
> in preparation for further refactoring.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Bart Van Assche
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes R
libata already uses an internal buffer, so we should be using
__scsi_format_command() here.
Cc: linux-...@vger.kernel.org
Cc: LKML
Reviewed-by: Christoph Hellwig
Acked-by: Tejun Heo
Signed-off-by: Hannes Reinecke
---
drivers/ata/libata-eh.c | 13 +
1 file changed, 5 insertions(+),
SPC-3 defines SERVICE ACTION IN(12) and SERVICE ACTION IN(16).
So rename SERVICE_ACTION_IN to SERVICE_ACTION_IN_16 to be
consistent with SPC and to allow for better distinction.
Reviewed-by: Christoph Hellwig
Signed-off-by: Hannes Reinecke
---
block/scsi_ioctl.c | 2 +-
The request tag provides a concise identification of a SCSI
command, so we should be printing that out for scmd_printk().
Suggested-by: Christoph Hellwig
Reviewed-by: Christoph Hellwig
Signed-off-by: Hannes Reinecke
---
drivers/scsi/scsi_logging.c | 4
1 file changed, 4 insertions(+)
dif
SPC-3 defines SERVICE ACTION IN(12), SERVICE_ACTION OUT(12),
SERVICE ACTION OUT(16), and SERVICE ACTION BIDIRECTIONAL.
And READ MEDIA SERIAL NUMBER has long since been deprecated.
So update callers to refer to the new cdb name.
Reviewed-by: Christoph Hellwig
Signed-off-by: Hannes Reinecke
---
d
Use an external buffer for __scsi_print_command() and
move command logging over to use the per-cpu logging
buffer. With that we can guarantee the command always
will always be formatted in one line.
So we can even print out a variable length command
correctly across several lines.
Finally rename __
Convert sense buffer logging to use the per-cpu
buffer to avoid line breakup.
Signed-off-by: Hannes Reinecke
---
drivers/scsi/constants.c| 107
drivers/scsi/scsi_logging.c | 167 +---
drivers/scsi/sd.c | 7 +-
d
Implement a per-cpu buffer for formatting messages to
avoid line break up under high load.
This patch implements scmd_printk() and sdev_prefix_printk()
using the per-cpu buffer and makes sdev_printk() a wrapper
for sdev_prefix_printk().
Signed-off-by: Hannes Reinecke
---
drivers/scsi/Makefile
Instead of having constants.c littered with ifdef statements
we should be moving dummy functions into the header and
condintionally compile in constants.c if selected.
Suggested-by: Christoph Hellwig
Reviewed-by: Christoph Hellwig
Signed-off-by: Hannes Reinecke
---
drivers/scsi/Makefile |
Hi all,
this is the second part of my scsi logging update, covering
CDB and sense code printing. With this patchset CDBs and
sense code bytes will be formatted on a single line
(where possible), and prefixed with the device and command
tag.
To ensure CDBs and sense code bytes are not broken up du
scsi_log_send() would display buffer pointer for higher
logging levels. This is not only of questionable value
but also exposes kernel pointer to userspace, which is
discouraged in some setups. So drop this message
altogether.
Signed-off-by: Hannes Reinecke
---
drivers/scsi/scsi.c | 9 +
Convert scsi_print_result() to use the per-cpu buffer for
decoding the command result and disposition.
Signed-off-by: Hannes Reinecke
---
drivers/scsi/constants.c| 22 --
drivers/scsi/scsi.c | 2 +-
drivers/scsi/scsi_logging.c | 44 +++
On Wed, 2014-11-05 at 11:30 -0800, Christoph Hellwig wrote:
> On Wed, Nov 05, 2014 at 11:34:11AM -0500, Alan Stern wrote:
> > > Sorry, meant to. In principle I'm OK with this as the lever for the
> > > hack (largely because it means we don't need to do anything) but will
> > > the distributions su
Hello,
I've got a big box of audio CDs to read, so I hooked up a load of SATA
CDROM drives to a machine (Intel motherboard AHCI, and SATA SiI3124
controllers - in this example one was attached to each host controller),
so that I could read them in parallel.
I'm using kernel 3.16.3, with cdparanoi
The result of a pointer subtraction has type ptrdiff_t. Hence change a
%ld format specifier into %td. This change avoids that the following
warning is printed on 32-bit systems:
warning: format '%ld' expects argument of type 'long int', but argument 5 has
type 'int' [-Wformat=]
Reported-by: Wu F
On 11/05/14 19:54, Christoph Hellwig wrote:
On Wed, Nov 05, 2014 at 01:37:14PM +0100, Bart Van Assche wrote:
That's strange. I have compared the patches that are already in your tree
with the patches I had posted myself with a diff tool. These patches look
identical to what I had posted except f
On 11/06/2014 12:30 PM, James Bottomley wrote:
> On Wed, 2014-11-05 at 11:30 -0800, Christoph Hellwig wrote:
>> On Wed, Nov 05, 2014 at 11:34:11AM -0500, Alan Stern wrote:
Sorry, meant to. In principle I'm OK with this as the lever for the
hack (largely because it means we don't need to
On 11/04/14 08:54, Christoph Hellwig wrote:
diff --git a/drivers/scsi/pmcraid.c b/drivers/scsi/pmcraid.c
index bcb64eb..2233ed6 100644
--- a/drivers/scsi/pmcraid.c
+++ b/drivers/scsi/pmcraid.c
@@ -321,16 +321,10 @@ static int pmcraid_change_queue_type(struct scsi_device
*scsi_dev, int tag)
On Thu, Nov 06, 2014 at 09:21:05AM +0100, Hannes Reinecke wrote:
> Hmm? Isn't there a scsi_put_comand() too many?
> You dropped it from the 'if' branch, moved it out of
> the condition, but kept in in the 'else' branch ...
The put_device for the 'else' branch was hidden inside scsi_next_command.
On Thu, Nov 06, 2014 at 03:18:12PM +0100, Bart Van Assche wrote:
> The result of a pointer subtraction has type ptrdiff_t. Hence change a
> %ld format specifier into %td. This change avoids that the following
> warning is printed on 32-bit systems:
>
> warning: format '%ld' expects argument of typ
On Thu, Nov 06, 2014 at 04:28:41PM +0100, Bart Van Assche wrote:
> A minor nit: do we really need to keep the scsi_dev->tagged_supported test
> in the above code ? Anyway,
It's not needed, but the whole function will go away later in the series.
--
To unsubscribe from this list: send the line "un
I tested a machine with multiple scsi adapters today with latest kernel
and found the following warning in the logs. It is probably from QLA1040
adapter initialization, full dmesg is below. Adaptec SCSI card dumps is
normal on this server, it is usually there and seems to be harmless
(maybe a s
On 11/04/14 08:54, Christoph Hellwig wrote:
Remove the ordered_tags field, we haven't been issuing ordered tags based
on it since the big barrier rework in 2010.
Reviewed-by: Bart Van Assche
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to ma
On 11/04/14 08:54, Christoph Hellwig wrote:
Signed-off-by: Christoph Hellwig
Reviewed-by: Bart Van Assche
--
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-inf
Without help from Paul I can't even make sense of the message..
On Thu, Nov 06, 2014 at 05:45:43PM +0200, Meelis Roos wrote:
> I tested a machine with multiple scsi adapters today with latest kernel
> and found the following warning in the logs. It is probably from QLA1040
> adapter initializati
On Thu, 6 Nov 2014, Boaz Harrosh wrote:
> On 11/06/2014 12:30 PM, James Bottomley wrote:
> > We really don't want to make the decision within the kernel of whether
> > we believe the partition size or the disk capacity. For these disk
> > problems we need it to be the former, but if we choose t
On Thu, 2014-11-06 at 16:33 +0200, Boaz Harrosh wrote:
> On 11/06/2014 12:30 PM, James Bottomley wrote:
> > On Wed, 2014-11-05 at 11:30 -0800, Christoph Hellwig wrote:
> >> On Wed, Nov 05, 2014 at 11:34:11AM -0500, Alan Stern wrote:
> Sorry, meant to. In principle I'm OK with this as the leve
On 11/04/14 08:54, Christoph Hellwig wrote:
-/**
- * scsi_activate_tcq - turn on tag command queueing
- * @SDpnt: device to turn on TCQ for
- * @depth: queue depth
- *
- * Notes:
- * Eventually, I hope depth would be the maximum depth
- * the device could cope with and the real qu
On Thu, Nov 06, 2014 at 05:28:32PM +0100, Bart Van Assche wrote:
> Apparently this patch removes the
> queue_flag_set_unlocked(QUEUE_FLAG_QUEUED, sdev->request_queue) call for
> the multiqueue case. I think it should be explained in the commit message
> why that has been done.
Ok, I will update
On 11/06/2014 05:54 PM, James Bottomley wrote:
>
> We don't have a failure. This is the problem. Determining that a
> problem exists
>
OK Sorry. I assumed the bridge is smart enough to do nothing,
ie READ_CAPACITY_10 is passed as is via sata to the device that
actually supports READ_CAPACITY
On 11/06/2014 05:53 PM, Alan Stern wrote:
>> But just the simple case of read-capacity failure should we then?
>
> That's a separate question. As far as I know, the case you are
> describing has not come up.
>
BTW: what we should do is when the partition parser at the block layer
see that the
Thanks,
applied both patches to the drivers-for-3.19 branch.
--
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
Thanks,
applied both patches to the drivers-for-3.18 branch.
--
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
Thanks,
applied to the drivers-for-3.18 branch.
--
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
On Thu, 6 Nov 2014, Boaz Harrosh wrote:
> On 11/06/2014 05:54 PM, James Bottomley wrote:
> >
> > We don't have a failure. This is the problem. Determining that a
> > problem exists
> >
>
> OK Sorry. I assumed the bridge is smart enough to do nothing,
>
> ie READ_CAPACITY_10 is passed as is
On Wed, Nov 05, 2014 at 14:54:43 -0500, David Miller wrote:
> From: Hariprasad Shenai
> Date: Tue, 4 Nov 2014 08:20:54 +0530
>
> > It's not really the "hardware" which generates these hardware constant
> > symbolic
> > macros/register defines of course, it's scripts developed by the hardware
>
On Thu, Nov 06, 2014 at 07:46:16AM -0800, Christoph Hellwig wrote:
> Without help from Paul I can't even make sense of the message..
It looks to me like the SUN4U architecture is failing to invoke
rcu_irq_enter() on entry to the smp_call_function_single_client()
IPI handler.
And I am not seeing a
From: Boaz Harrosh
> On 11/06/2014 05:53 PM, Alan Stern wrote:
> >> But just the simple case of read-capacity failure should we then?
> >
> > That's a separate question. As far as I know, the case you are
> > describing has not come up.
> >
>
> BTW: what we should do is when the partition parser
On 11/06/2014 10:47 AM, Chris Friesen wrote:
Hi,
I'm running a modified 3.4-stable on relatively recent X86 server-class
hardware.
I recently installed a Seagate ST900MM0026 (900GB 2.5in 10K SAS drive)
and it's reporting a value of 4294966784 for optimal_io_size. The other
parameters look norm
On Thu, 2014-11-06 at 17:08 +, David Laight wrote:
> From: Boaz Harrosh
> > On 11/06/2014 05:53 PM, Alan Stern wrote:
> > >> But just the simple case of read-capacity failure should we then?
> > >
> > > That's a separate question. As far as I know, the case you are
> > > describing has not com
> "Chris" == Chris Friesen writes:
Chris> Perhaps the ST900MM0026 should be blacklisted as well?
Sure. I'll widen the net a bit for that Seagate model.
commit 17f1ee2d16a6878269c4429306f6e678b7e61505
Author: Martin K. Petersen
Date: Thu Nov 6 12:31:43 2014 -0500
SCSI: Blacklist ST90
On 11/06/2014 11:34 AM, Martin K. Petersen wrote:
"Chris" == Chris Friesen writes:
Chris> Perhaps the ST900MM0026 should be blacklisted as well?
Sure. I'll widen the net a bit for that Seagate model.
That'd work, but is it the best way to go? I mean, I found one report
of a similar proble
On Wed, 5 Nov 2014, Dale R. Worley wrote:
> > From: Alan Stern
>
> > I posted a patch to allow the user to override the reported capacity:
> >
> > http://marc.info/?l=linux-scsi&m=140993840113445&w=2
>
> I see the patch, and I feel confident I could install it if I needed
> to. What comma
Christoph, this fixes the build failure from the previous patch. Sorry about
that. Please apply to drivers-for-3.18 as well.
-Anish
Signed-off-by: Anish Bhatt
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb
> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of Christoph Hellwig
> Sent: Thursday, 30 October, 2014 4:27 AM
> To: linux-scsi@vger.kernel.org
> Cc: Douglas Gilbert; Elliott, Robert (Server Storage)
> Subject: [PATCH 1
> "Chris" == Chris Friesen writes:
Chris> That'd work, but is it the best way to go? I mean, I found one
Chris> report of a similar problem on an SSD (model number unknown). In
Chris> that case it was a near-UINT_MAX value as well.
My concern is still the same. Namely that this particular
On 2014-11-06 11:12, Martin K. Petersen wrote:
"Chris" == Chris Friesen writes:
Chris> That'd work, but is it the best way to go? I mean, I found one
Chris> report of a similar problem on an SSD (model number unknown). In
Chris> that case it was a near-UINT_MAX value as well.
My concern is
Hi Finn,
>> Leaves the current instability - I did some work on the CT60 accelerator
>> (reflashed the firmware so I can use the CTPCI board). This might have
>> caused the system to become more unstable. Needs more investigation.
>
> I gather from the emails we've exchanged that the "current" ins
On 11/06/2014 12:12 PM, Martin K. Petersen wrote:
"Chris" == Chris Friesen
writes:
Chris> That'd work, but is it the best way to go? I mean, I found
one Chris> report of a similar problem on an SSD (model number
unknown). In Chris> that case it was a near-UINT_MAX value as well.
My concern
> From: "Theodore Ts'o"
>
> On Wed, Nov 05, 2014 at 05:07:48PM +0100, James Bottomley wrote:
> >
> > OK, but I still don't understand how windows gets the partition table on
> > there in the first place ... that must surely be some sort of guess the
> > disk size hack.
>
> 99% of the time the p
> From: James Bottomley
>
> We really don't want to make the decision within the kernel of whether
> we believe the partition size or the disk capacity. For these disk
> problems we need it to be the former, but if we choose that always,
> we'll get weird results on mispartitioned devices.
>
>
On Thu, 6 Nov 2014, Dale R. Worley wrote:
> There is one thing that seems like it might be a problem: We have to
> ensure that the SCSI driver can read the partition tables (in the
> standard locations) even if it doesn't know how big the disk is.
A DOS partition table is stored in the first 512
Connection retries were not being cleaned up correctly if they failed as a
result of link down. Applies on top of drivers-for-3.18.
v2 : Previous patch casued a build failure and was backed out. Fixed and
verified with this patch.
Signed-off-by: Anish Bhatt
Signed-off-by: Karen Xie
---
driv
The first patch is unchanged and fold the logic back to scsi_dh_alua.c for
the second patch.
Thanks for your help!
Wendy
--
--
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
This patch fixes an issue with multipath ipr SAS devices which require a
start unit command to be issued following an adapter reset. Without this
patch, paths get marked failed following an adapter reset and since the
error handler never gets invoked to issue the start unit, the paths are
never rec
Multipath devices using the TUR path checker need to see the sense
code for a failed TUR command in their device handler. Since commit
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/
drivers/scsi/scsi_error.c?id=14216561e164671ce147458653b1fea06a
we always return success for
> -Original Message-
> From: Christoph Hellwig [mailto:h...@lst.de]
> Sent: Thursday, 30 October, 2014 4:27 AM
> To: linux-scsi@vger.kernel.org
> Cc: Douglas Gilbert; Elliott, Robert (Server Storage)
> Subject: [PATCH 3/6] sd: fix up ->compat_ioctl
>
> No need to verify the passthrough i
> -Original Message-
> From: Christoph Hellwig [mailto:h...@lst.de]
> Sent: Thursday, 30 October, 2014 4:27 AM
> To: linux-scsi@vger.kernel.org
> Cc: Douglas Gilbert; Elliott, Robert (Server Storage)
> Subject: [PATCH 6/6] scsi: return EAGAIN when resetting a device
> under EH
>
> Signed
From: Hariprasad S
Date: Thu, 6 Nov 2014 21:45:10 +0530
> On Wed, Nov 05, 2014 at 14:54:43 -0500, David Miller wrote:
>> From: Hariprasad Shenai
>> Date: Tue, 4 Nov 2014 08:20:54 +0530
>>
>> > It's not really the "hardware" which generates these hardware constant
>> > symbolic
>> > macros/reg
> -Original Message-
> From: Christoph Hellwig [mailto:h...@lst.de]
> Sent: Thursday, 30 October, 2014 4:27 AM
> To: linux-scsi@vger.kernel.org
> Cc: Douglas Gilbert; Elliott, Robert (Server Storage)
> Subject: [PATCH 2/6] scsi: split scsi_nonblockable_ioctl
>
> The calling conventions for
On 14-11-06 04:46 PM, Elliott, Robert (Server Storage) wrote:
-Original Message-
From: Christoph Hellwig [mailto:h...@lst.de]
Sent: Thursday, 30 October, 2014 4:27 AM
To: linux-scsi@vger.kernel.org
Cc: Douglas Gilbert; Elliott, Robert (Server Storage)
Subject: [PATCH 6/6] scsi: return
3.13.11.11 -stable review patch. If anyone has any objections, please let me
know.
--
From: Jan Kara
commit 84ce0f0e94ac97217398b3b69c21c7a62ebeed05 upstream.
When sg_scsi_ioctl() fails to prepare request to submit in
blk_rq_map_kern() we jump to a label where we just end up
> -Original Message-
> From: Christoph Hellwig [mailto:h...@lst.de]
> Sent: Thursday, 30 October, 2014 4:27 AM
> To: linux-scsi@vger.kernel.org
> Cc: Douglas Gilbert; Elliott, Robert (Server Storage)
> Subject: [PATCH 4/6] st: call scsi_set_medium_removal directly
>
> Signed-off-by: Christ
> -Original Message-
> From: Christoph Hellwig [mailto:h...@lst.de]
> Sent: Thursday, 30 October, 2014 4:27 AM
> To: linux-scsi@vger.kernel.org
> Cc: Douglas Gilbert; Elliott, Robert (Server Storage)
> Subject: [PATCH 5/6] osst: call scsi_set_medium_removal directly
>
> Signed-off-by: Ch
Fix 'ioctl' spelling.
Signed-off-by: Alex Pilon
---
drivers/scsi/mpt2sas/mpt2sas_ctl.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/mpt2sas/mpt2sas_ctl.h
b/drivers/scsi/mpt2sas/mpt2sas_ctl.h
index fa0567c..7f842c8 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_ctl
> "Chris" == Chris Friesen writes:
Chris,
Chris> For a RAID card I expect it would be related to chunk size or
Chris> stripe width or something...but even then I would expect to be
Chris> able to cap it at 100MB or so. Or are there storage systems on
Chris> really fast interfaces that could
On Fri, 7 Nov 2014, Michael Schmitz wrote:
> it's probably not Geert but James who needs to give the go-ahead.
Given Geert's objections to the changes under arch/m68k in v1, I'm hoping
for an acked-by from Geert for v2...
--
--
To unsubscribe from this list: send the line "unsubscribe linux-s
Hi,
This series moves the debugfs code to a new file debugfs.c and cleans up
macros/register defines.
Various patches have ended up changing the style of the symbolic macros/register
defines and some of them used the macros/register defines that matches the
output of the script from the hardware
Signed-off-by: Hariprasad Shenai
---
drivers/net/ethernet/chelsio/cxgb4/Makefile|1 +
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h |1 +
drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 158
drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.h | 52
Various patches have ended up changing the style of the symbolic macros/register
defines to different style.
As a result, the current kernel.org files are a mix of different macro styles.
Since this macro/register defines is used by different drivers a
few patch series have ended up adding duplica
Various patches have ended up changing the style of the symbolic macros/register
to different style.
As a result, the current kernel.org files are a mix of different macro styles.
Since this macro/register defines is used by different drivers a
few patch series have ended up adding duplicate macro
If READ_CAPACITY_10 returns something that looks valid but might be off
by a multiple of 2TB, and READ_CAPACITY_16 fails, what do we really want
to do when we read the partition table?
If the partition table indicates that everything fits in the capacity
returned by READ_CAPACITY_10, great, it is
As defined, the DRAT (Deterministic Read After Trim) and RZAT (Return
Zero After Trim) flags in the ATA Command Set are unreliable in the
sense that they only define what happens if the device successfully
executed the DSM TRIM command. TRIM is only advisory, however, and the
device is free to sile
This update is mainly motivated by an attempt to make the
discard_zeroes_data reporting more accurate. As we have discussed
several times in the past we are stuck with pretty weak guarantees from
the T10/T13 standards. And as a result we feel compelled to tighten up
the scenarios under which we adv
The T10 SBC UNMAP command does not provide any hard guarantees that
blocks will return zeroes on a subsequent READ. This is due to the fact
that the device server is free to silently ignore all or parts of the
request.
The only way to ensure that a block consistently returns zeroes after
being unm
blkdev_issue_discard() will zero a given block range on disk. This is
done by way of either WRITE SAME or regular WRITE. I.e. the blocks on
disk will be written and thus provisioned.
There are use cases where the desired behavior is to zero the blocks but
unprovision them if possible. The blocks m
On 11/06/2014 07:56 PM, Martin K. Petersen wrote:
"Chris" == Chris Friesen writes:
Chris,
Chris> For a RAID card I expect it would be related to chunk size or
Chris> stripe width or something...but even then I would expect to be
Chris> able to cap it at 100MB or so. Or are there storage syst
Pegasus is a high performance hardware RAID solution designed to unleash the
raw power of Thunderbolt technology.
I add code to distinct SuperTrack and Pegasus series by subID.
It's needed for backward compatibility.
Change the driver version.
Signed-off-by: Charles Chiou
---
drivers/scsi/st
Pegasus is a high performance hardware RAID solution designed to unleash
the raw power of Thunderbolt technology.
I add code to distinct SuperTrack and Pegasus series by subID.
It's needed for backward compatibility.
Change the driver version.
---
drivers/scsi/stex.c | 24 +++
84 matches
Mail list logo
