Re: [Drbd-dev] RFC: always use REQ_OP_WRITE_ZEROES for zeroing offload

On Mon, 2017-03-27 at 10:03 -0400, Mike Snitzer wrote: > As for the blkdev_issue_zeroout() resorting to manually zeroing the > range, if the discard fails or dzd not supported, that certainly > requires DM thinp to implement manual zeroing of the head and tail of > the range if partial blocks are

Re: [PATCH] sd: Consider max_xfer_blocks if opt_xfer_blocks is unusable

- Original Message - > From: "Fam Zheng" > To: linux-ker...@vger.kernel.org > Cc: "Martin K. Petersen" , f...@redhat.com, > linux-scsi@vger.kernel.org, "James E.J. > Bottomley" > Sent: Monday, March 27, 2017

Re: RFC: always use REQ_OP_WRITE_ZEROES for zeroing offload

On Mon, Mar 27, 2017 at 10:03:07AM -0400, Mike Snitzer wrote: > By "you" I assume you're referring to Lars? Yes. > Lars' approach for discard, > when drbd is layered on dm-thinp, feels over-engineered. Not his fault, > the way discard and zeroing got conflated certainly lends itself to > these

[PATCHv5 1/2] tcmu: Fix possible overwrite of t_data_sg's last iov[]

From: Xiubo Li If there has BIDI data, its first iov[] will overwrite the last iov[] for se_cmd->t_data_sg. To fix this, we can just increase the iov pointer, but this may introuduce a new memory leakage bug: If the se_cmd->data_length and

[PATCHv5 0/2] tcmu: For bugs fix only

From: Xiubo Li Changed for V5: - This only includes #1 and #2. And for old #3, #4 are still reviewing. - #1, since the issue reported by Ilias is a separate new one, and will create a new patch later. - #2, address the issue pointed out by Mike, thanks. - #1 and

Re: [PATCH 06/23] dm-kcopyd: switch to use REQ_OP_WRITE_ZEROES

On Thu, Mar 23, 2017 at 11:10:38AM -0400, Mike Snitzer wrote: > Not sure why you've split out the dm-kcopyd patch, likely best to just > fold it into the previous dm support patch. The dm-kcopyd patch switches to using WRITE_ZEROES instead of write same for dm as user of these interfaces. The

[PATCHv5 2/2] tcmu: Fix wrongly calculating of the base_command_size

From: Xiubo Li The t_data_nents and t_bidi_data_nents are the numbers of the segments, but it couldn't be sure the block size equals to size of the segment. For the worst case, all the blocks are discontiguous and there will need the same number of iovecs, that's

Re: RFC: always use REQ_OP_WRITE_ZEROES for zeroing offload

It sounds like you don't want to support traditional discard at all, but only WRITE ZEROES. So in many ways this series is the right way forward. It would be nice if we could do a full blown REQ_OP_WRITE_ZEROES for dm_think that zeroes out partial blocks, similar to what hardware that implements

[REGRESSION][Stable][v3.12.y][v4.4.y][v4.9.y][v4.10.y][v4.11-rc1] scsi: storvsc: properly set residual data length on errors

Hi Long Li, A kernel bug report was opened against Ubuntu [0]. After a kernel bisect, it was found that reverting the following commit resolved this bug: commit 40630f462824ee24bc00d692865c86c3828094e0 Author: Long Li Date: Wed Dec 14 18:46:03 2016 -0800 scsi:

Re: [PATCH] scsi: ufs: remove the duplicated checking for supporting clkscaling

Jaehoon Chung writes: Jaehoon, > There are same conditions for checking whether supporting clkscaling > or not. When ufshcd is supporting clkscaling, active_reqs should be > decreased by two. Applied to 4.11/scsi-fixes. Thank you! -- Martin K. Petersen Oracle

Re: [PATCH] scsi: osd_uld: remove an unneeded NULL check

Dan Carpenter writes: > We don't call the remove() function unless probe() succeeds so "oud" > can't be NULL here. Plus, if it were NULL, we dereference it on the > next line so it would crash anyway. Applied to 4.12/scsi-queue (by hand). -- Martin K. Petersen

Re: [PATCH] scsi: ufs: fix wrong/ambiguous fall through comments

kusumi.tomoh...@gmail.com writes: > From: Tomohiro Kusumi > > These aren't really falling through to anywhere meaningful. > > Signed-off-by: Tomohiro Kusumi Applied to 4.12/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH v3 00/10] be2iscsi: driver update 11.4.0.0

Jitendra Bhivare writes: > This patch is generated against for-next branch. > > v3 changes: > be2iscsi: Fix closing of connection > - Fixed per Tomas's review comments. > > v2 changes: > +be2iscsi: Update Copyright > > Jitendra Bhivare (10): > be2iscsi:

Re: [PATCH] sd: Consider max_xfer_blocks if opt_xfer_blocks is unusable

Fam Zheng writes: Hi Fam, > --- a/drivers/scsi/sd.c > +++ b/drivers/scsi/sd.c > @@ -2957,6 +2957,7 @@ static int sd_revalidate_disk(struct gendisk *disk) > rw_max = logical_to_sectors(sdp, sdkp->opt_xfer_blocks); > } else > rw_max =

RE: [REGRESSION][Stable][v3.12.y][v4.4.y][v4.9.y][v4.10.y][v4.11-rc1] scsi: storvsc: properly set residual data length on errors

Are you sure the real problem is not the one fixed by this commit? commit f1c635b439a5c01776fe3a25b1e2dc546ea82e6f Author: Stephen Hemminger Date: Tue Mar 7 09:15:53 2017 -0800 scsi: storvsc: Workaround for virtual DVD SCSI version Hyper-V host

Re: [PATCH 1/7] ѕd: split sd_setup_discard_cmnd

On Mon, 2017-03-20 at 16:43 -0400, Christoph Hellwig wrote: > + u64 sector = blk_rq_pos(rq) >> (ilog2(sdp->sector_size) - 9); > + u32 nr_sectors = blk_rq_sectors(rq) >> (ilog2(sdp->sector_size) - 9); Although I know this is an issue in the existing code and not something introduced by

Re: [REGRESSION][Stable][v3.12.y][v4.4.y][v4.9.y][v4.10.y][v4.11-rc1] scsi: storvsc: properly set residual data length on errors

On 03/27/2017 06:14 PM, Stephen Hemminger wrote: > Are you sure the real problem is not the one fixed by this commit? > > commit f1c635b439a5c01776fe3a25b1e2dc546ea82e6f > Author: Stephen Hemminger > Date: Tue Mar 7 09:15:53 2017 -0800 > > scsi: storvsc:

Re: [PATCH 2/7] sd: provide a new ata trim provisioning mode

On Mon, 2017-03-20 at 16:43 -0400, Christoph Hellwig wrote: > + case SD_LBP_ATA_TRIM: > + max_blocks = 65535 * (512 / sizeof(__le64)); > + if (sdkp->device->ata_trim_zeroes_data) > + q->limits.discard_zeroes_data = 1; > + break; Do we

Re: [PATCH 5/7] block: add a max_discard_segment_size queue limit

On Mon, 2017-03-20 at 16:43 -0400, Christoph Hellwig wrote: > diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h > index 5a7da607ca04..3b3bd646f580 100644 > --- a/include/linux/blkdev.h > +++ b/include/linux/blkdev.h > @@ -333,6 +333,7 @@ struct queue_limits { > unsigned short

Re: [PATCH 6/7] sd: support multi-range TRIM for ATA disks

On Mon, 2017-03-20 at 16:43 -0400, Christoph Hellwig wrote: > @@ -698,13 +698,19 @@ static void sd_config_discard(struct scsi_disk *sdkp, > unsigned int mode) > break; > > case SD_LBP_ATA_TRIM: > - max_blocks = 65535 * (512 / sizeof(__le64)); > +

Re: [PATCH 7/7] sd: use ZERO_PAGE for WRITE_SAME payloads

On Mon, 2017-03-20 at 16:43 -0400, Christoph Hellwig wrote: > We're never touching the contents of the page, so save a memory > allocation for these cases. > > Signed-off-by: Christoph Hellwig > --- > drivers/scsi/sd.c | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-)

[PATCH v2] sd: Consider max_xfer_blocks if opt_xfer_blocks is unusable

If device reports a small max_xfer_blocks and a zero opt_xfer_blocks, we end up using BLK_DEF_MAX_SECTORS, which is wrong and r/w of that size may get error. Fixes: ca369d51b3e ("block/sd: Fix device-imposed transfer length limits") Signed-off-by: Fam Zheng --- v2: Fix

Delock 89384 Sata Controller Causes Lockups Under Heavy Load

Hello, I'm new to this list and I signed up, because I found an instability with the following sata controller: Product name: Delock 89384 10 Port PCIe 2.0 x2 Low Profile retail Identifies as: 03:00.0 SATA controller: ASMedia Technology Inc. Device 0625 (rev 01) (PCIe to 10x sata controller

[PATCH] sd: Consider max_xfer_blocks if opt_xfer_blocks is unusable

If device reports a small max_xfer_blocks and a zero opt_xfer_blocks, we end up using BLK_DEF_MAX_SECTORS, which is wrong and r/w of that size may get error. Fixes: ca369d51b3e ("block/sd: Fix device-imposed transfer length limits") Signed-off-by: Fam Zheng ---

Re: RFC: always use REQ_OP_WRITE_ZEROES for zeroing offload

On Mon, Mar 27 2017 at 5:10am -0400, Christoph Hellwig wrote: > It sounds like you don't want to support traditional discard at all, > but only WRITE ZEROES. So in many ways this series is the right way > forward. It would be nice if we could do a full blown >