<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/scsi/sd.h, branch linux-4.5.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.5.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.5.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2016-04-20T06:45:23Z</updated>
<entry>
<title>sd: Fix excessive capacity printing on devices with blocks bigger than 512 bytes</title>
<updated>2016-04-20T06:45:23Z</updated>
<author>
<name>Martin K. Petersen</name>
</author>
<published>2016-03-29T01:18:56Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0cfb108d055a9c4ee9fffdcfa3481db9dc995d1c'/>
<id>urn:sha1:0cfb108d055a9c4ee9fffdcfa3481db9dc995d1c</id>
<content type='text'>
commit f08bb1e0dbdd0297258d0b8cd4dbfcc057e57b2a upstream.

During revalidate we check whether device capacity has changed before we
decide whether to output disk information or not.

The check for old capacity failed to take into account that we scaled
sdkp-&gt;capacity based on the reported logical block size. And therefore
the capacity test would always fail for devices with sectors bigger than
512 bytes and we would print several copies of the same discovery
information.

Avoid scaling sdkp-&gt;capacity and instead adjust the value on the fly
when setting the block device capacity and generating fake C/H/S
geometry.

Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Reported-by: Hannes Reinecke &lt;hare@suse.de&gt;
Reviewed-by: Hannes Reinicke &lt;hare@suse.de&gt;
Reviewed-by: Ewan Milne &lt;emilne@redhat.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>block/sd: Fix device-imposed transfer length limits</title>
<updated>2015-11-26T02:38:58Z</updated>
<author>
<name>Martin K. Petersen</name>
</author>
<published>2015-11-13T21:46:48Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ca369d51b3e1649be4a72addd6d6a168cfb3f537'/>
<id>urn:sha1:ca369d51b3e1649be4a72addd6d6a168cfb3f537</id>
<content type='text'>
Commit 4f258a46346c ("sd: Fix maximum I/O size for BLOCK_PC requests")
had the unfortunate side-effect of removing an implicit clamp to
BLK_DEF_MAX_SECTORS for REQ_TYPE_FS requests in the block layer
code. This caused problems for some SMR drives.

Debugging this issue revealed a few problems with the existing
infrastructure since the block layer didn't know how to deal with
device-imposed limits, only limits set by the I/O controller.

 - Introduce a new queue limit, max_dev_sectors, which is used by the
   ULD to signal the maximum sectors for a REQ_TYPE_FS request.

 - Ensure that max_dev_sectors is correctly stacked and taken into
   account when overriding max_sectors through sysfs.

 - Rework sd_read_block_limits() so it saves the max_xfer and opt_xfer
   values for later processing.

 - In sd_revalidate() set the queue's max_dev_sectors based on the
   MAXIMUM TRANSFER LENGTH value in the Block Limits VPD. If this value
   is not reported, fall back to a cap based on the CDB TRANSFER LENGTH
   field size.

 - In sd_revalidate(), use OPTIMAL TRANSFER LENGTH from the Block Limits
   VPD--if reported and sane--to signal the preferred device transfer
   size for FS requests. Otherwise use BLK_DEF_MAX_SECTORS.

 - blk_limits_max_hw_sectors() is no longer used and can be removed.

Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93581
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Tested-by: sweeneygj@gmx.com
Tested-by: Arzeets &lt;anatol.pomozov@gmail.com&gt;
Tested-by: David Eisner &lt;david.eisner@oriel.oxon.org&gt;
Tested-by: Mario Kicherer &lt;dev@kicherer.org&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
</entry>
<entry>
<title>scsi: introduce sdev_prefix_printk()</title>
<updated>2014-11-12T10:15:57Z</updated>
<author>
<name>Hannes Reinecke</name>
</author>
<published>2014-10-24T12:26:44Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=22e0d994151c3eac183625f8c1400c0c83ac414f'/>
<id>urn:sha1:22e0d994151c3eac183625f8c1400c0c83ac414f</id>
<content type='text'>
Like scmd_printk(), but the device name is passed in as
a string. Can be used by eg ULDs which do not have access
to the scsi_cmnd structure.

Signed-off-by: Hannes Reinecke &lt;hare@suse.de&gt;
Reviewed-by: Robert Elliott &lt;elliott@hp.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
</content>
</entry>
<entry>
<title>sd: Honor block layer integrity handling flags</title>
<updated>2014-09-30T21:17:35Z</updated>
<author>
<name>Martin K. Petersen</name>
</author>
<published>2014-09-26T23:20:08Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c611529e7cd3465ec0eada0f44200e8420c38908'/>
<id>urn:sha1:c611529e7cd3465ec0eada0f44200e8420c38908</id>
<content type='text'>
A set of flags introduced in the block layer enable better control over
how protection information is handled. These flags are useful for both
error injection and data recovery purposes. Checking can be enabled and
disabled for controller and disk, and the guard tag format is now a
per-I/O property.

Update sd_protect_op to communicate the relevant information to the
low-level device driver via a set of flags in scsi_cmnd.

Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Reviewed-by: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Acked-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Jens Axboe &lt;axboe@fb.com&gt;
</content>
</entry>
<entry>
<title>sd: Limit transfer length</title>
<updated>2014-07-17T20:07:33Z</updated>
<author>
<name>Martin K. Petersen</name>
</author>
<published>2014-06-03T22:45:51Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=bcdb247c6b6a1f3e72b9b787b73f47dd509d17ec'/>
<id>urn:sha1:bcdb247c6b6a1f3e72b9b787b73f47dd509d17ec</id>
<content type='text'>
Until now the per-command transfer length has exclusively been gated by
the max_sectors parameter in the scsi_host template. Given that the size
of this parameter has been bumped to an unsigned int we have to be
careful not to exceed the target device's capabilities.

If the if the device specifies a Maximum Transfer Length in the Block
Limits VPD we'll use that value. Otherwise we'll use 0xffffffff for
devices that have use_16_for_rw set and 0xffff for the rest. We then
combine the chosen disk limit with max_sectors in the host template. The
smaller of the two will be used to set the max_hw_sectors queue limit.

Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Reviewed-by: Ewan D. Milne &lt;emilne@redhat.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
</content>
</entry>
<entry>
<title>[SCSI] sd: Quiesce mode sense error messages</title>
<updated>2014-03-27T15:26:33Z</updated>
<author>
<name>Martin K. Petersen</name>
</author>
<published>2014-01-03T23:19:26Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b2bff6ceb61a9a21294f04057d30c9bb4910a88f'/>
<id>urn:sha1:b2bff6ceb61a9a21294f04057d30c9bb4910a88f</id>
<content type='text'>
Messages about discovered disk properties are only printed once unless
they are found to have changed. Errors encountered during mode sense,
however, are printed every time we revalidate.

Quiesce mode sense errors so they are only printed during the first
scan.

[jejb: checkpatch fixes]
Bugzilla: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733565
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
</content>
</entry>
<entry>
<title>[SCSI] Derive the FLUSH_TIMEOUT from the basic I/O timeout</title>
<updated>2013-10-25T08:58:16Z</updated>
<author>
<name>James Bottomley</name>
</author>
<published>2013-10-04T21:42:24Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=7e660100d85af860e7ad763202fff717adcdaacd'/>
<id>urn:sha1:7e660100d85af860e7ad763202fff717adcdaacd</id>
<content type='text'>
Rather than having a separate constant for specifying the timeout on FLUSH
operations, use the basic I/O timeout value that is already configurable
on a per target basis to derive the FLUSH timeout. Looking at the current
definitions of these timeout values, the FLUSH operation is supposed to have
a value that is twice the normal timeout value. This patch preserves this
relationship while leveraging the flexibility of specifying the I/O timeout.

Based on a prior patch by KY Srinivasan &lt;kys@microsoft.com&gt;

Reviewed-by: KY Srinivasan &lt;kys@microsoft.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
</content>
</entry>
<entry>
<title>[SCSI] sd: Update WRITE SAME heuristics</title>
<updated>2013-06-27T00:56:18Z</updated>
<author>
<name>Martin K. Petersen</name>
</author>
<published>2013-06-07T02:15:55Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=66c28f97120e8a621afd5aa7a31c4b85c547d33d'/>
<id>urn:sha1:66c28f97120e8a621afd5aa7a31c4b85c547d33d</id>
<content type='text'>
SATA drives located behind a SAS controller would incorrectly receive
WRITE SAME commands. Tweak the heuristics so that:

 - If REPORT SUPPORTED OPERATION CODES is provided we will use that to
   choose between WRITE SAME(16), WRITE SAME(10) and disabled. This also
   fixes an issue with the old code which would issue WRITE SAME(10)
   despite the command not being whitelisted in REPORT SUPPORTED
   OPERATION CODES.

 - If REPORT SUPPORTED OPERATION CODES is not provided we will fall back
   to WRITE SAME(10) unless the device has an ATA Information VPD page.
   The assumption is that a SATL which is smart enough to implement
   WRITE SAME would also provide REPORT SUPPORTED OPERATION CODES.

To facilitate the new heuristics scsi_report_opcode() has been modified
to so we can distinguish between "operation not supported" and "RSOC not
supported".

Reported-by: H. Peter Anvin &lt;hpa@zytor.com&gt;
Tested-by: Bernd Schubert &lt;bernd.schubert@itwm.fraunhofer.de&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
</content>
</entry>
<entry>
<title>[SCSI] sd: fix array cache flushing bug causing performance problems</title>
<updated>2013-05-02T23:15:54Z</updated>
<author>
<name>James Bottomley</name>
</author>
<published>2013-04-24T21:02:53Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=39c60a0948cc06139e2fbfe084f83cb7e7deae3b'/>
<id>urn:sha1:39c60a0948cc06139e2fbfe084f83cb7e7deae3b</id>
<content type='text'>
Some arrays synchronize their full non volatile cache when the sd driver sends
a SYNCHRONIZE CACHE command.  Unfortunately, they can have Terrabytes of this
and we send a SYNCHRONIZE CACHE for every barrier if an array reports it has a
writeback cache.  This leads to massive slowdowns on journalled filesystems.

The fix is to allow userspace to turn off the writeback cache setting as a
temporary measure (i.e. without doing the MODE SELECT to write it back to the
device), so even though the device reported it has a writeback cache, the
user, knowing that the cache is non volatile and all they care about is
filesystem correctness, can turn that bit off in the kernel and avoid the
performance ruinous (and safety irrelevant) SYNCHRONIZE CACHE commands.

The way you do this is add a 'temporary' prefix when performing the usual
cache setting operations, so

echo temporary write through &gt; /sys/class/scsi_disk/&lt;disk&gt;/cache_type

Reported-by: Ric Wheeler &lt;rwheeler@redhat.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
</content>
</entry>
<entry>
<title>[SCSI] sd: Implement support for WRITE SAME</title>
<updated>2012-11-14T06:45:42Z</updated>
<author>
<name>Martin K. Petersen</name>
</author>
<published>2012-09-18T16:19:32Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5db44863b6ebbb400c5e61d56ebe8f21ef48b1bd'/>
<id>urn:sha1:5db44863b6ebbb400c5e61d56ebe8f21ef48b1bd</id>
<content type='text'>
Implement support for WRITE SAME(10) and WRITE SAME(16) in the SCSI disk
driver.

 - We set the default maximum to 0xFFFF because there are several
   devices out there that only support two-byte block counts even with
   WRITE SAME(16). We only enable transfers bigger than 0xFFFF if the
   device explicitly reports MAXIMUM WRITE SAME LENGTH in the BLOCK
   LIMITS VPD.

 - max_write_same_blocks can be overriden per-device basis in sysfs.

 - The UNMAP discovery heuristics remain unchanged but the discard
   limits are tweaked to match the "real" WRITE SAME commands.

 - In the error handling logic we now distinguish between WRITE SAME
   with and without UNMAP set.

The discovery process heuristics are:

 - If the device reports a SCSI level of SPC-3 or greater we'll issue
   READ SUPPORTED OPERATION CODES to find out whether WRITE SAME(16) is
   supported. If that's the case we will use it.

 - If the device supports the block limits VPD and reports a MAXIMUM
   WRITE SAME LENGTH bigger than 0xFFFF we will use WRITE SAME(16).

 - Otherwise we will use WRITE SAME(10) unless the target LBA is beyond
   0xFFFFFFFF or the block count exceeds 0xFFFF.

 - no_write_same is set for ATA, FireWire and USB.

Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Reviewed-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
Reviewed-by: Jeff Garzik &lt;jgarzik@redhat.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
</content>
</entry>
</feed>
