From patchwork Mon Aug 14 21:13:26 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tom Yan X-Patchwork-Id: 9900171 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 35AE5602CA for ; Mon, 14 Aug 2017 21:13:42 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2899B2875A for ; Mon, 14 Aug 2017 21:13:42 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 1D3E528737; Mon, 14 Aug 2017 21:13:42 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.5 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B080D28742 for ; Mon, 14 Aug 2017 21:13:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752381AbdHNVNl (ORCPT ); Mon, 14 Aug 2017 17:13:41 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:33249 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752133AbdHNVNk (ORCPT ); Mon, 14 Aug 2017 17:13:40 -0400 Received: by mail-wm0-f67.google.com with SMTP id q189so15840164wmd.0 for ; Mon, 14 Aug 2017 14:13:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:from:to:cc:subject:date; bh=YJB4T8nUKTboDH0RZrSDc7U6J7c5a/6/xSpTXak30Gs=; b=SaX5KwBT+vfzBbWbW47RZmvltu8+njr5dOLXjbRDkiJCCW76aAvTzfffbLZQHHJplO TRoEKE0vAz88gvXjtTe0SAX7q520rIk92aA+Ssd7r1oH6zf98Yax+cfqivgjdXkuCZDT yGtbi3LMDq+DgG/Qzj8I5Jgvwg9bSbi7mdF2HEMw0+FaGqf0+leJVWvBNiAP1f5bEc91 YGkTpl5qgCDBrJmEU8sGNkD2hAxKkFWsl64FBNcY9SAZ/q9HtCQfcL8nyUlHMqc78tLL +HZWlV6RZBveqGp/XQCRobPO8LppJGtSB7qK8DKcOSv290MHOKTng5l9aIYaYlUskAOi aO7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:from:to:cc:subject:date; bh=YJB4T8nUKTboDH0RZrSDc7U6J7c5a/6/xSpTXak30Gs=; b=h1p7v1M9N6oLfq1ZxjScKraQVWVCnOlAkxzDd4vfDH+4qwb5/+wa9AgGDWlbFqnZKK OicJidJqk7pNQuDep0YhcJZuFHqDc5OoFdw0nJY4NGGarcDdb3t6k6CBLChOLx9c8YeK X2p+hYHSX7gw/gLQdvqn0JCaa76CkULfgAtQpMVZsvgzZMR4ZFPIYtQzYk6vzkfWeJVV UsdM38xoYz/odFc3bATJGWBjFoj7JkRJmepF4Z2nBymE0iEpBHfenmrrH0Gy9CJmyi+c VOZK+be8tRpZF5TYAXN/Bcw66zmEWXzbiYXpNbErZQ67q8Y5/Vky8WteTwP4y6PJQic+ BitQ== X-Gm-Message-State: AHYfb5hRDioNnDI7CIt4wvyxtBkI55sQaW0xAt2KacEEPQcKHTrfG1Si 4rwutcHnPWHAZX5D X-Received: by 10.28.129.70 with SMTP id c67mr120180wmd.175.1502745218875; Mon, 14 Aug 2017 14:13:38 -0700 (PDT) Received: from localhost.localdomain (server88-208-246-128.live-servers.net. [88.208.246.128]) by smtp.gmail.com with ESMTPSA id b186sm235555wma.24.2017.08.14.14.13.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Aug 2017 14:13:38 -0700 (PDT) Message-ID: <59921282.c3341c0a.a8437.1b70@mx.google.com> X-Google-Original-Message-ID: <20170814211326.1481-1-me> From: tom.ty89@gmail.com X-Google-Original-From: me To: martin.petersen@oracle.com Cc: linux-scsi@vger.kernel.org, Tom Yan Subject: [PATCH] sd: read unmap block limits even if lbpme=0 Date: Tue, 15 Aug 2017 05:13:26 +0800 X-Mailer: git-send-email 2.14.1 Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Tom Yan Some devices may not be decent enough to report lbpme bit properly even when they do support unmap and report relevant information in the block limits and logical block provisioning VPDs properly (Namely, ASMedia ASM1351, a UAS-SATA bridge). One of the reasons is, lbpme=1 is not a requirement for "DeleteNotify" in Windows to be activated: [root@archlinux ~]# sg_readcap -l /dev/sda | grep lb Logical block provisioning: lbpme=0, lbprz=0 [root@archlinux ~]# sg_vpd -p lbpv /dev/sda | grep \(LB Unmap command supported (LBPU): 1 Write same (16) with unmap bit supported (LBWS): 0 Write same (10) with unmap bit supported (LBWS10): 0 Logical block provisioning read zeros (LBPRZ): 0 [root@archlinux ~]# sg_vpd -p bl /dev/sda | grep -i unmap Maximum unmap LBA count: 4194240 Maximum unmap block descriptor count: 1 Optimal unmap granularity: 1 Unmap granularity alignment valid: 0 Unmap granularity alignment: 0 While there may be a point to retain the "strict policy" on this, by not configuring discard for such device automatically, there is little reason not to read the relevant data from the VPD, for users are allowed to configure discard for a device via the provisioning_mode sysfs file. While discard_max_bytes can be changed manually, it is better if the value would be limited by a discard_max_hw_bytes that is set from the hardware limit that is reported in the VPD. Before this commit: [root@archlinux ~]# cat (...)/provisioning_mode full [root@archlinux ~]# grep . /sys/block/sda/queue/discard_* /sys/block/sda/queue/discard_granularity:0 /sys/block/sda/queue/discard_max_bytes:0 /sys/block/sda/queue/discard_max_hw_bytes:0 /sys/block/sda/queue/discard_zeroes_data:0 [root@archlinux ~]# echo -n unmap > (...)/provisioning_mode [root@archlinux ~]# grep . /sys/block/sda/queue/discard_* /sys/block/sda/queue/discard_granularity:512 /sys/block/sda/queue/discard_max_bytes:4294966784 /sys/block/sda/queue/discard_max_hw_bytes:4294966784 /sys/block/sda/queue/discard_zeroes_data:0 After this commit: [root@archlinux ~]# cat (...)/provisioning_mode full [root@archlinux ~]# grep . /sys/block/sda/queue/discard_* /sys/block/sda/queue/discard_granularity:0 /sys/block/sda/queue/discard_max_bytes:0 /sys/block/sda/queue/discard_max_hw_bytes:0 /sys/block/sda/queue/discard_zeroes_data:0 [root@archlinux ~]# echo -n unmap > (...)/provisioning_mode [root@archlinux ~]# grep . /sys/block/sda/queue/discard_* /sys/block/sda/queue/discard_granularity:512 /sys/block/sda/queue/discard_max_bytes:2147450880 /sys/block/sda/queue/discard_max_hw_bytes:2147450880 /sys/block/sda/queue/discard_zeroes_data:0 Signed-off-by: Tom Yan diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index bea36adeee17..ea9e6fc76b63 100644 --- a/drivers/scsi/sd.c +++ b/drivers/scsi/sd.c @@ -2883,9 +2883,6 @@ static void sd_read_block_limits(struct scsi_disk *sdkp) sdkp->max_ws_blocks = (u32)get_unaligned_be64(&buffer[36]); - if (!sdkp->lbpme) - goto out; - lba_count = get_unaligned_be32(&buffer[20]); desc_count = get_unaligned_be32(&buffer[24]); @@ -2898,6 +2895,9 @@ static void sd_read_block_limits(struct scsi_disk *sdkp) sdkp->unmap_alignment = get_unaligned_be32(&buffer[32]) & ~(1 << 31); + if (!sdkp->lbpme) + goto out; + if (!sdkp->lbpvpd) { /* LBP VPD page not provided */ if (sdkp->max_unmap_blocks)