On 6/11/2014 12:17 AM, Quinn Tran wrote:
QT> Instead of using existing value within cmd->data_length, can we
calculated data_length based on secstors & blocksize.
cmd->data_length = sectors * dev->dev_attrib.block_size;
We can do that I suppose...
Although it seems weird that the core disca
On Tue, Jun 10, 2014 at 02:20:28PM -0700, Nicholas A. Bellinger wrote:
> On Tue, 2014-06-10 at 13:56 -0700, Linus Torvalds wrote:
> > On Tue, Jun 10, 2014 at 1:25 PM, Nicholas A. Bellinger
> > wrote:
> > >
> > > That would work, or I can simply include a pointer to Stephen's patch in
> > > the tar
In case protection information exists over the wire
iscsi header data length is required to include it.
Use protection information aware scsi helpers to set
the correct transfer length.
In order to avoid breakage, remove iser transfer length
checks for each task as they are not always true and
som
At the SCSI transport level, there is no distinction between
user data and protection information. Thus, iscsi header field
"expected data transfer length" should include protection
information.
Patch #1 introduces scsi helper scsi_transfer_length which computes
wire transfer byte count.
Patch #2
In case protection information exists on the wire
scsi transports should include it in the transfer
byte count (even if protection information does not
exist in the host memory space). This helper will
compute the total transfer length from the scsi
command data length and protection attributes.
S
In various areas of the code, it is assumed that
se_cmd->data_length describes pure data. In case
that protection information exists over the wire
(protect bits is are on) the target core re-calculates
the data length from the CDB and the backed device
block size (instead of each transport peeking
After this first pull for the 3.16 merge window it seems like this
worked out fairly well - we got a large number of patches in, and all
reviewed by a second pair of eyes.
How should we go on from this? The drivers-for-3.16-2 branch, which had
the late lpfs and hpsa updates didn't make it into th
The whole series looks good to me,
Reviewed-by: Christoph Hellwig
--
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 Tue, Jun 03, 2014 at 05:37:30PM +0800, Vaughan Cao wrote:
> This is a fix for commit:
> 39c60a0948cc06139e2fbfe084f83cb7e7deae3b sd: fix array cache flushing bug
> causing performance problems
> We must notify the block layer via q->flush_flags after temporary change the
> cache_type to writ
Looks good,
Reviewed-by: Christoph Hellwig
--
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 Tue, Jun 10, 2014 at 12:00:39PM +0200, Xose Vazquez Perez wrote:
> resent to linux-scsi-ml, without the binary blob(244K).
>
> Firmwares were taken from http://ldriver.qlogic.com/firmware/
Looks good, while there's nothing really to review for a firmware blob
update, can you get me a review or
Looks good,
Reviewed-by: Christoph Hellwig
--
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, Jun 05, 2014 at 11:29:47PM +0200, Arnd Bergmann wrote:
> The pas16 scsi driver does not use DMA, and the call to free_dma()
> in its exit function seems to have been copied incorrectly from
> another driver but never caused trouble.
>
> One case where it gets in the way is randconfig build
On Thu, Jun 05, 2014 at 11:29:48PM +0200, Arnd Bergmann wrote:
> The qlogicfas scsi driver does not use DMA, and the call to free_dma()
> in its exit function seems to have been copied incorrectly from
> another driver but never caused trouble.
>
> One case where it gets in the way is randconfig b
On Thu, Jun 05, 2014 at 11:29:49PM +0200, Arnd Bergmann wrote:
> The NCR53c406a scsi driver normally does not use DMA, unless
> the USE_PIO macro is disabled by modifying the source code.
>
> The call to free_dma() for some reason uses #ifdef USE_DMA,
> which does not do the right thing, since USE
Can I get a second review on this one from anyone?
On Wed, Jun 04, 2014 at 01:34:56PM +0200, Paolo Bonzini wrote:
> Calling the workqueue interface on uninitialized work items isn't a
> good idea even if they're zeroed. It's not failing catastrophically only
> through happy accidents.
>
> Signed-
On Thu, Jun 05, 2014 at 09:26:43AM +0200, Hannes Reinecke wrote:
> As per SAM there is a status precedence, with any sense code 29/XX
> taking second place just after an ACA ACTIVE status.
> Additionally, each target might prefer to not queue any unit
> attention conditions but just report one.
> D
On Wed, Jun 11, 2014 at 02:53:46PM +0200, Paolo Bonzini wrote:
> Messaggio originale
> From: Christoph Hellwig
> To: Paolo Bonzini
> Cc: linux-ker...@vger.kernel.org, linux-scsi@vger.kernel.org, h...@lst.de,
> jbottom...@parallels.com, venkate...@google.com
> Subject: Re
On Mon, Jun 09, 2014 at 10:29:06AM -0700, James Bottomley wrote:
> I'll do it as a bug fix, but I do need Jens to make sure nothing else
> breaks first. Best I can tell, the state model for compound commands
> like flush doesn't expect us to change the request type ... nothing puts
> it back to RE
Hi Linus,
Please pull the following.
Please note this needs to be merged before merging
target-pending PULL which Nicholas will be sending
out shortly.
Thanks!
The following changes since commit 1860e379875dfe7271c649058aeddffe5afd9d0d:
Linux 3.15 (2014-06-08 11:19:54 -0700)
are available in
On 14-06-11 02:53 AM, Bart Van Assche wrote:
On 06/11/14 08:34, Hannes Reinecke wrote:
On 06/10/2014 07:58 PM, Bart Van Assche wrote:
Many SCSI LLD's use int_to_scsilun() in the hot path (queuecommand()).
This patch series makes the int_to_scsilun() function slightly more
expensive. Has it been
On Thu, Jun 05, 2014 at 09:26:42AM +0200, Hannes Reinecke wrote:
> REPORT_LUN_SCAN does not report any outstanding unit attention
> condition as per SAM. However, the target might not be fully
> initialized at that time, so we might end up getting a
> default entry (or even a partially filled one).
On Thu, 2014-06-05 at 09:26 +0200, Hannes Reinecke wrote:
> As per SAM there is a status precedence, with any sense code 29/XX
> taking second place just after an ACA ACTIVE status.
> Additionally, each target might prefer to not queue any unit
> attention conditions but just report one.
> Due to t
On Wed, 2014-06-11 at 05:01 -0700, Christoph Hellwig wrote:
> After this first pull for the 3.16 merge window it seems like this
> worked out fairly well - we got a large number of patches in, and all
> reviewed by a second pair of eyes.
>
> How should we go on from this? The drivers-for-3.16-2 b
On Thu, 2014-06-05 at 09:26 +0200, Hannes Reinecke wrote:
> REPORT_LUN_SCAN does not report any outstanding unit attention
> condition as per SAM. However, the target might not be fully
> initialized at that time, so we might end up getting a
> default entry (or even a partially filled one).
> But
On Wed, Jun 11, 2014 at 07:17:34AM -0700, James Bottomley wrote:
> No, I was waiting to check if there was any reason to have them split,
> but I think we've scope today or tomorrow.
>
> The only other outstanding thing is the fsync bug fix, which is waiting
> Jens' investigation of the block issu
On 06/11/2014 04:24 PM, James Bottomley wrote:
On Thu, 2014-06-05 at 09:26 +0200, Hannes Reinecke wrote:
REPORT_LUN_SCAN does not report any outstanding unit attention
condition as per SAM. However, the target might not be fully
initialized at that time, so we might end up getting a
default entr
On Wed, 2014-06-11 at 16:33 +0200, Hannes Reinecke wrote:
> On 06/11/2014 04:24 PM, James Bottomley wrote:
> > On Thu, 2014-06-05 at 09:26 +0200, Hannes Reinecke wrote:
> >> REPORT_LUN_SCAN does not report any outstanding unit attention
> >> condition as per SAM. However, the target might not be fu
On 6/11/2014 9:33 AM, Hannes Reinecke wrote:
> _If_ we were attempting this we'd run into several issues: a) Boot will
> fail, as REPORT LUNs will return 0 LUNs (or just LUN 0). So the scanning
> code will assume everything's fine. Booting will continue, only to figure
> out that no LUNs are presen
On 06/11/2014 04:46 PM, James Bottomley wrote:
On Wed, 2014-06-11 at 16:33 +0200, Hannes Reinecke wrote:
On 06/11/2014 04:24 PM, James Bottomley wrote:
On Thu, 2014-06-05 at 09:26 +0200, Hannes Reinecke wrote:
REPORT_LUN_SCAN does not report any outstanding unit attention
condition as per SAM.
On Wed, 2014-06-11 at 17:13 +0200, Hannes Reinecke wrote:
> On 06/11/2014 04:46 PM, James Bottomley wrote:
> > On Wed, 2014-06-11 at 16:33 +0200, Hannes Reinecke wrote:
> >> On 06/11/2014 04:24 PM, James Bottomley wrote:
> >>> On Thu, 2014-06-05 at 09:26 +0200, Hannes Reinecke wrote:
> REPORT_
On Wed, 2014-06-04 at 10:58 -0400, Douglas Gilbert wrote:
> When the SG_IO ioctl was copied into the block layer and
> later into the bsg driver, subtle differences emerged.
>
> One difference is the way injected commands are queued through
> the block layer (i.e. this is not SCSI device queueing
On Wed, May 28, 2014 at 11:28:35PM -0400, Martin K. Petersen wrote:
> bdev_integrity_enabled() is only used by bio_integrity_enabled().
> Combine these two functions.
>
> Signed-off-by: Martin K. Petersen
Looks good,
Reviewed-by: Christoph Hellwig
--
To unsubscribe from this list: send the lin
On Wed, May 28, 2014 at 11:28:36PM -0400, Martin K. Petersen wrote:
> For commands like REQ_COPY we need a way to pass extra information along
> with each bio. Like integrity metadata this information must be
> available at the bottom of the stack so bi_private does not suffice.
>
> Rename the exi
On Wed, May 28, 2014 at 11:28:37PM -0400, Martin K. Petersen wrote:
> None of the filesystems appear interested in using the integrity tagging
> feature. Potentially because very few storage devices actually permit
> using the application tag space.
>
> Deprecate the tagging functions.
This patch
On Wed, May 28, 2014 at 11:28:38PM -0400, Martin K. Petersen wrote:
> bip_buf is not really needed so we can remove it.
>
> Signed-off-by: Martin K. Petersen
Looks good,
Reviewed-by: Christoph Hellwig
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a mes
On Wed, May 28, 2014 at 11:28:39PM -0400, Martin K. Petersen wrote:
> The protection interval is not necessarily tied to the logical block
> size of a block device. Stop using the terms sector and sectors.
This does more than just renaming symbols, so it needs a better
description or even better s
On Wed, May 28, 2014 at 11:28:41PM -0400, Martin K. Petersen wrote:
> Add a BLK_ prefix to the integrity profile flags. Also rename the flags
> to be more consistent with the generate/verify terminology in the rest
> of the integrity code.
>
> Signed-off-by: Martin K. Petersen
Looks good,
Revie
On Wed, May 28, 2014 at 11:28:43PM -0400, Martin K. Petersen wrote:
> Move flags affecting the integrity code out of the bio bi_flags and into
> the block integrity payload.
It seems like bip is guaranteed to be non-NULL in all callers of the
getters and setters. I'd recommend just dropping them
On Wed, May 28, 2014 at 11:28:44PM -0400, Martin K. Petersen wrote:
> Make the choice of checksum a per-I/O property by introducing a flag
> that can be inspected by the SCSI layer.
Why?
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...
On Wed, May 28, 2014 at 11:28:45PM -0400, Martin K. Petersen wrote:
> We'd occasionally merge requests with conflicting integrity flags.
> Introduce a merge helper which checks that the requests have compatible
> integrity payloads.
Looks good,
Reviewed-by: Christoph Hellwig
--
To unsubscribe fr
On Wed, May 28, 2014 at 11:28:46PM -0400, Martin K. Petersen wrote:
> Introduce a set of error codes that can be used by the block integrity
> subsystem to signal which class of error was encountered by either the
> I/O controller or the storage device.
>
> Signed-off-by: Martin K. Petersen
New
On Wed, May 28, 2014 at 11:28:42PM -0400, Martin K. Petersen wrote:
> So far we have relied on the app tag size to determine whether a disk
> has been formatted with T10 protection information or not. However, not
> all target devices provide application tag storage.
>
> Add a flag to the block in
> static struct blk_integrity dif_type1_integrity_crc = {
>
> .name = "T10-DIF-TYPE1-CRC",
> - .generate_fn= sd_dif_type1_generate_crc,
> - .verify_fn = sd_dif_type1_verify_crc,
> - .tuple_size = sizeof(struct sd_dif_tuple),
On 11.6.2014, at 2.48, Laurence Oberman wrote:
> Hello
>
> Take 2 of this patch, changed module description and subject line.
>
> This patch adds a debug_flag parameter that can be set on module load, and
> allows the DEBUG facility without a module recompile.
> Usage: mpdprobe st debug_flag=
Kai,
Thank you for considering this.
With #define DEBUG 0
We still include
#define DEB(a)
#define DEBC(a)
With the debug_flag we then provide the needed debug I am looking for at module
load time.
But I agree that it enables it for all devices and that may not be optimal
I don't change the defa
unsigned value is never < 0
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Fabian Frederick
---
drivers/message/i2o/i2o_block.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/message/i2o/i2o_block.c b/drivers/message/i2o/i2o_block.c
index 6fc3866..2b684ec 100644
--- a
This thread leads me to ask: Do people use ANSI-formatted tapes any
more? That is, tape volumes with miltiple files, header and trailer
labels, etc.?
Dale
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo
Kai,
Its likely not worth doing this, I cross checked and indeed many distros have
this compiled out.
So lets leave it as is.
Thanks
Laurence
- Original Message -
From: "Laurence Oberman"
To: "Kai Mäkisara (Kolumbus)"
Cc: linux-scsi@vger.kernel.org
Sent: Wednesday, June 11, 2014 2:24:
On 06/04/2014 09:58 AM, Douglas Gilbert wrote:
> When the SG_IO ioctl was copied into the block layer and
> later into the bsg driver, subtle differences emerged.
>
> One difference is the way injected commands are queued through
> the block layer (i.e. this is not SCSI device queueing nor SATA
>
On Wed, 2014-06-11 at 10:24 +0300, Sagi Grimberg wrote:
> On 6/11/2014 12:17 AM, Quinn Tran wrote:
>
>
>
> > QT> Instead of using existing value within cmd->data_length, can we
> > calculated data_length based on secstors & blocksize.
> >
> > cmd->data_length = sectors * dev->dev_attrib.block_si
On 06/05/2014 09:02 AM, Douglas Gilbert wrote:
> After the SG_IO ioctl was copied into the block layer and
> later into the bsg driver, subtle differences emerged.
>
> One difference is the way injected commands are queued through
> the block layer (i.e. this is not SCSI device queueing nor SATA
>
On Wed, 2014-06-11 at 12:09 +0300, Sagi Grimberg wrote:
> At the SCSI transport level, there is no distinction between
> user data and protection information. Thus, iscsi header field
> "expected data transfer length" should include protection
> information.
>
> Patch #1 introduces scsi helper scs
On 06/03/2014 12:18 PM, Douglas Gilbert wrote:
> v4 of this patch was sent 20131201.
>
> ChangeLog:
> - remove the 16 byte CDB (SCSI command) length limit
> from the sg driver by handling longer CDBs the same
> way as the bsg driver. Remove comment from sg.h
>
On 6/11/14 2:30 PM, "Nicholas A. Bellinger" wrote:
>On Wed, 2014-06-11 at 10:24 +0300, Sagi Grimberg wrote:
>> On 6/11/2014 12:17 AM, Quinn Tran wrote:
>>
>>
>>
>> > QT> Instead of using existing value within cmd->data_length, can we
>> > calculated data_length based on secstors & blocksize.
>
> "nab" == Nicholas A Bellinger writes:
nab> Hard to say. Discarding the transport length in v2 doesn't seem
nab> like a good idea, but subtracting from cmd->prot_length in v1 is
nab> using the sector count from the CDB anyways, so it's essentially
nab> the same tradeoff of recalculating the
> "Sagi" == Sagi Grimberg writes:
Sagi> In case protection information exists on the wire scsi transports
Sagi> should include it in the transfer byte count (even if protection
Sagi> information does not exist in the host memory space). This helper
Sagi> will compute the total transfer length
> "Christoph" == Christoph Hellwig writes:
>> Deprecate the tagging functions.
Christoph> This patch doesn't just deprecate them but outright removes
Christoph> them.
Fixed.
--
Martin K. Petersen Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe li
> "Christoph" == Christoph Hellwig writes:
Christoph> Instead of having a union of pointer just make it a void
Christoph> pointer. I also think special is a terribly generic name, but
Christoph> I don't really have a better idea at hand.
I needed something that could encompass additional inf
> "Christoph" == Christoph Hellwig writes:
Christoph> On Wed, May 28, 2014 at 11:28:39PM -0400, Martin K. Petersen wrote:
>> The protection interval is not necessarily tied to the logical block
>> size of a block device. Stop using the terms sector and sectors.
Christoph> This does more than
> "Christoph" == Christoph Hellwig writes:
Hey Christoph,
>> Add a flag to the block integrity profile that indicates whether the
>> disk has been formatted with protection information.
Christoph> I'm totally confused on why the sysfs file and flag are named
Christoph> 'disk'. What does it
> "Christoph" == Christoph Hellwig writes:
Christoph> On Wed, May 28, 2014 at 11:28:43PM -0400, Martin K. Petersen wrote:
>> Move flags affecting the integrity code out of the bio bi_flags and
>> into the block integrity payload.
Christoph> It seems like bip is guaranteed to be non-NULL in a
> "Christoph" == Christoph Hellwig writes:
>> Make the choice of checksum a per-I/O property by introducing a flag
>> that can be inspected by the SCSI layer.
Christoph> Why?
First of all it's desirable to be able to use both IP and CRC checksums
without having to unload the HBA driver.
Al
> "Christoph" == Christoph Hellwig writes:
>> Introduce a set of error codes that can be used by the block
>> integrity subsystem to signal which class of error was encountered by
>> either the I/O controller or the storage device.
Christoph> I'd also love to see something catching these so
> "Christoph" == Christoph Hellwig writes:
>> static struct blk_integrity dif_type1_integrity_crc = {
Christoph> Shouldn't the whole profile defintions move to the generic
Christoph> code as well?
Yeah, good idea.
Christoph> Maybe the code also should live in block/ and not lib/.
Fine by
On Wed, 2014-06-11 at 22:32 +, Quinn Tran wrote:
>
> On 6/11/14 2:30 PM, "Nicholas A. Bellinger" wrote:
>
> >On Wed, 2014-06-11 at 10:24 +0300, Sagi Grimberg wrote:
> >> On 6/11/2014 12:17 AM, Quinn Tran wrote:
> >>
> >>
> >>
> >> > QT> Instead of using existing value within cmd->data_lengt
66 matches
Mail list logo
