From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com [209.85.167.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6E09F33C7 for ; Wed, 6 Apr 2022 17:28:30 +0000 (UTC) Received: by mail-lf1-f45.google.com with SMTP id d5so5274245lfj.9 for ; Wed, 06 Apr 2022 10:28:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WJLYFFwKJzu0AzBejzceyC93Fh4AhvIk3A/MNZXzKIU=; b=nHoFYmIVcbUdYBuRBczLdRhO5AcYZ6GHHFtKpS9G1n5vNIpBGLipmKmQ40hQnwfBEK 9YcCx5HGe8T4NG1UPywpqZKblDsiU8Uam6EvTYaei53mUEV7gX/X6QEIMPDVNdTe1RsC lSqUADllCjDlRJ3aqfDHj4gGsZ5WvTndElsOvm3ukXbURNWbOjm9tS3FKy9TW5JIte+s iqchodtdlLO+0839AsHapTHL+am4rmkQFqKuweIuQiuTq0iA/dxkHoEkiJl793SmXbAL d6FIVbXVTWtg6j4nPkHK8I7vb1+rBuBMN5T4ZVmgoa+qulAgS9/S0AV92hnwAdWJS/in gNUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WJLYFFwKJzu0AzBejzceyC93Fh4AhvIk3A/MNZXzKIU=; b=1VofBQYNWhI9WDkV1fpnIreHETNaKanh5gSkph3ET7yIfBHGcwmnzOoSjR6y5IQGia 8Ik+8RHyeyqVfav4/KqiUkPsBzp1QDa8OQr4amM2kKeGDrBYaMWkP3N3zAxjHdwak76c Xj3kxdzp9BjNv5L8AV3PSNV8baYNggAp8DUNvMf2WSjYuncnZuAhPTl5cAaCo8/g91gQ I1EzurRiVs20A55iYPJfmSyPaGaGJgSdNWXPaHz1Bt/x12mCReg+MR4SR4zIXXPIWjWF WpahKlskZV+E892ds0qv4jwzior7T54/cSPw/nBGcWvM8b9uPrVvfnPJ+NNcHxQ0xjpY qJJA== X-Gm-Message-State: AOAM533NfRY5STBH971/R9V46OrnMccKPY1kVoFGe294ZZ1A4XUNc6lY nyqqvPMebZTJv5wlYmG/hB5aT1o1h/tpLLIAJs8= X-Google-Smtp-Source: ABdhPJxvT7YhfWN8QbCVz4oydCsKwT/zbXQ5089WXaSZlqzdjbFflulVc086iBmKtewP4KtbC66vp+jW8qrWjcRFTmg= X-Received: by 2002:ac2:5f4d:0:b0:43e:da3e:4529 with SMTP id 13-20020ac25f4d000000b0043eda3e4529mr6768924lfz.627.1649266108188; Wed, 06 Apr 2022 10:28:28 -0700 (PDT) Precedence: bulk X-Mailing-List: ntfs3@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20220406060516.409838-1-hch@lst.de> <20220406060516.409838-24-hch@lst.de> In-Reply-To: <20220406060516.409838-24-hch@lst.de> From: Ryusuke Konishi Date: Thu, 7 Apr 2022 02:28:15 +0900 Message-ID: Subject: Re: [PATCH 23/27] block: add a bdev_max_discard_sectors helper To: Christoph Hellwig Cc: Andreas Gruenbacher , Jens Axboe , device-mapper development , linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-um@lists.infradead.org, linux-block@vger.kernel.org, drbd-dev@lists.linbit.com, nbd@other.debian.org, ceph-devel@vger.kernel.org, virtualization@lists.linux-foundation.org, xen-devel@lists.xenproject.org, linux-bcache@vger.kernel.org, linux-raid@vger.kernel.org, linux-mmc@vger.kernel.org, linux-mtd@lists.infradead.org, linux-nvme@lists.infradead.org, linux-s390@vger.kernel.org, linux-scsi@vger.kernel.org, target-devel@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, cluster-devel@redhat.com, jfs-discussion@lists.sourceforge.net, linux-nilfs , ntfs3@lists.linux.dev, ocfs2-devel@oss.oracle.com, Linux MM Content-Type: text/plain; charset="UTF-8" On Wed, Apr 6, 2022 at 11:05 PM Christoph Hellwig wrote: > > Add a helper to query the number of sectors support per each discard bio > based on the block device and use this helper to stop various places from > poking into the request_queue to see if discard is supported and if so how > much. This mirrors what is done e.g. for write zeroes as well. > > Signed-off-by: Christoph Hellwig > --- ... > diff --git a/drivers/target/target_core_device.c b/drivers/target/target_core_device.c > index 16e775bcf4a7c..7d510e4231713 100644 > --- a/drivers/target/target_core_device.c > +++ b/drivers/target/target_core_device.c > @@ -829,9 +829,7 @@ struct se_device *target_alloc_device(struct se_hba *hba, const char *name) > } > > /* > - * Check if the underlying struct block_device request_queue supports > - * the QUEUE_FLAG_DISCARD bit for UNMAP/WRITE_SAME in SCSI + TRIM > - * in ATA and we need to set TPE=1 > + * Check if the underlying struct block_device request_queue supports disard. > */ Here was a typo: s/disard/discard/ On Thu, Apr 7, 2022 at 12:19 AM Andreas Gruenbacher wrote: > If I'm misreading things, could you please document that > bdev_max_discard_sectors() != 0 implies that discard is supported? I got the same impression. Checking the discard support with bdev_max_discard_sectors() != 0 seems a bit unclear than before. Thanks, Ryusuke Konishi From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 75915C433F5 for ; Wed, 6 Apr 2022 17:28:43 +0000 (UTC) Received: from [127.0.0.1] (helo=sfs-ml-1.v29.lw.sourceforge.com) by sfs-ml-1.v29.lw.sourceforge.com with esmtp (Exim 4.94.2) (envelope-from ) id 1nc9ST-0005QF-9F; Wed, 06 Apr 2022 17:28:40 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-1.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nc9SR-0005Q4-Ou; Wed, 06 Apr 2022 17:28:38 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=Content-Type:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Sender:Reply-To:Content-Transfer-Encoding :Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=WJLYFFwKJzu0AzBejzceyC93Fh4AhvIk3A/MNZXzKIU=; b=HOW8cV7JGRQBTSx8vyaVRloa93 IjO4rWUUmeI1yNyl+nhaqtpdjtMBRoB1STN7FpUVu3gOaXp+09x3HsXsnmoS8q4IMyonmtZW9QBZZ WYdc5XIPANOknTSBGlomTj8Ylpcly4awaZ6VSv8i8sr4MIMLu+snQfMSFK9dJHWw/hgc=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References: MIME-Version:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=WJLYFFwKJzu0AzBejzceyC93Fh4AhvIk3A/MNZXzKIU=; b=ShWu1+ryGRGEsCM5fV4Nz960FT 5pfz2s/Z9QeuSOhQbRk4sT3NBE9TBH5DA+2BDNIHNw9sGNgLHtbZn5mmI+k2XPUcIsRdxSFdJ7juI FSFmnd8ttqPcAnBRDLxqwC/nSrB8UdJAY3GE7iJH02CrtRbsenTyC6DVBR76f88fqzF0=; Received: from mail-lf1-f54.google.com ([209.85.167.54]) by sfi-mx-2.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.94.2) id 1nc9SN-0001EH-7u; Wed, 06 Apr 2022 17:28:38 +0000 Received: by mail-lf1-f54.google.com with SMTP id t25so5293727lfg.7; Wed, 06 Apr 2022 10:28:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WJLYFFwKJzu0AzBejzceyC93Fh4AhvIk3A/MNZXzKIU=; b=nHoFYmIVcbUdYBuRBczLdRhO5AcYZ6GHHFtKpS9G1n5vNIpBGLipmKmQ40hQnwfBEK 9YcCx5HGe8T4NG1UPywpqZKblDsiU8Uam6EvTYaei53mUEV7gX/X6QEIMPDVNdTe1RsC lSqUADllCjDlRJ3aqfDHj4gGsZ5WvTndElsOvm3ukXbURNWbOjm9tS3FKy9TW5JIte+s iqchodtdlLO+0839AsHapTHL+am4rmkQFqKuweIuQiuTq0iA/dxkHoEkiJl793SmXbAL d6FIVbXVTWtg6j4nPkHK8I7vb1+rBuBMN5T4ZVmgoa+qulAgS9/S0AV92hnwAdWJS/in gNUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WJLYFFwKJzu0AzBejzceyC93Fh4AhvIk3A/MNZXzKIU=; b=5xACKV5WVSsVjLXWGHnj7PCFtxf5F6bKvPWjwo1xEXYWBX7aTIBpWe4EooEh0Kz046 TYsBfKGx1cIAy4Ybr2Cdex1pzJQqeoXKG58KmBQwnbatIPzZ6uzb9P9ZZJZfNBc42fuJ /yxGlbRcH35/VR+59AHH+p0N/OtLjuTLUmm5TThME3Z/72ONrnpS7evxSXJuYQ+ORzAy EI8j3gbqnJKJkVGEMYA00skXY5jbPLQKGQUiT51AkJAVk+D8akXRBergTKR2wXs4311D tMCmk3E8naX7LnQXJbCw9uGfcpO0yvXn75a6Genle33AP19KyfZ8xX+ndBBFKdroVUnr 1QGw== X-Gm-Message-State: AOAM532k/e5hGMrJeAhgXSFVbvjV/clnS+QX8W68aOycp3j/xpugS3o9 3PcDd8eWJHRki3R3cEy78aNAorG5nF359h8l+YE= X-Google-Smtp-Source: ABdhPJxvT7YhfWN8QbCVz4oydCsKwT/zbXQ5089WXaSZlqzdjbFflulVc086iBmKtewP4KtbC66vp+jW8qrWjcRFTmg= X-Received: by 2002:ac2:5f4d:0:b0:43e:da3e:4529 with SMTP id 13-20020ac25f4d000000b0043eda3e4529mr6768924lfz.627.1649266108188; Wed, 06 Apr 2022 10:28:28 -0700 (PDT) MIME-Version: 1.0 References: <20220406060516.409838-1-hch@lst.de> <20220406060516.409838-24-hch@lst.de> In-Reply-To: <20220406060516.409838-24-hch@lst.de> From: Ryusuke Konishi Date: Thu, 7 Apr 2022 02:28:15 +0900 Message-ID: To: Christoph Hellwig X-Headers-End: 1nc9SN-0001EH-7u Subject: Re: [f2fs-dev] [PATCH 23/27] block: add a bdev_max_discard_sectors helper X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: jfs-discussion@lists.sourceforge.net, linux-nvme@lists.infradead.org, virtualization@lists.linux-foundation.org, Linux MM , device-mapper development , target-devel@vger.kernel.org, linux-mtd@lists.infradead.org, drbd-dev@lists.linbit.com, linux-s390@vger.kernel.org, linux-nilfs , Andreas Gruenbacher , linux-scsi@vger.kernel.org, cluster-devel@redhat.com, xen-devel@lists.xenproject.org, linux-ext4@vger.kernel.org, linux-um@lists.infradead.org, nbd@other.debian.org, linux-block@vger.kernel.org, linux-bcache@vger.kernel.org, ceph-devel@vger.kernel.org, Jens Axboe , linux-raid@vger.kernel.org, linux-mmc@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-xfs@vger.kernel.org, ocfs2-devel@oss.oracle.com, linux-fsdevel@vger.kernel.org, ntfs3@lists.linux.dev, linux-btrfs@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net On Wed, Apr 6, 2022 at 11:05 PM Christoph Hellwig wrote: > > Add a helper to query the number of sectors support per each discard bio > based on the block device and use this helper to stop various places from > poking into the request_queue to see if discard is supported and if so how > much. This mirrors what is done e.g. for write zeroes as well. > > Signed-off-by: Christoph Hellwig > --- ... > diff --git a/drivers/target/target_core_device.c b/drivers/target/target_core_device.c > index 16e775bcf4a7c..7d510e4231713 100644 > --- a/drivers/target/target_core_device.c > +++ b/drivers/target/target_core_device.c > @@ -829,9 +829,7 @@ struct se_device *target_alloc_device(struct se_hba *hba, const char *name) > } > > /* > - * Check if the underlying struct block_device request_queue supports > - * the QUEUE_FLAG_DISCARD bit for UNMAP/WRITE_SAME in SCSI + TRIM > - * in ATA and we need to set TPE=1 > + * Check if the underlying struct block_device request_queue supports disard. > */ Here was a typo: s/disard/discard/ On Thu, Apr 7, 2022 at 12:19 AM Andreas Gruenbacher wrote: > If I'm misreading things, could you please document that > bdev_max_discard_sectors() != 0 implies that discard is supported? I got the same impression. Checking the discard support with bdev_max_discard_sectors() != 0 seems a bit unclear than before. Thanks, Ryusuke Konishi _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 4ADBCC43217 for ; Wed, 6 Apr 2022 17:29:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=DcxquJyPwnb7SDo8wdswmgSqdagvlt6zNmHb4u28ZgE=; b=QzuSxdsy4y9JnK vrlimr42dso4svszstWzsF5KnTVBFL7pWc01o+wvxr5bzg33sB1JXbn5YSrW7ApujyXOrPYlQ9e14 kl3n7VDB6Ng5PwA7t3BKsuAUUZolhFeVJ+eJcdu2UGWd3tlPy2AZPpl+lrt2pm6JZZUDIXswWeoCN ixAT9Ho+BRbk1epBxLkGfey77LPAfRYwCVMoA+Vevk0ORGguEKTnCSOFtFoq+6DZQXto9233csxeP rAlIlEFoTYzQNhGCI4+Nkq5u2HqYy5zS+yzF2+lIRXdNAPSA2IsQY4ShAx4LPh075kENsIzYKwNu0 nskcaCv01sufqCYyJAIQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nc9SO-007N4s-8L; Wed, 06 Apr 2022 17:28:36 +0000 Received: from mail-lf1-x12c.google.com ([2a00:1450:4864:20::12c]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nc9SK-007N2p-OO; Wed, 06 Apr 2022 17:28:34 +0000 Received: by mail-lf1-x12c.google.com with SMTP id p10so5242768lfa.12; Wed, 06 Apr 2022 10:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WJLYFFwKJzu0AzBejzceyC93Fh4AhvIk3A/MNZXzKIU=; b=nHoFYmIVcbUdYBuRBczLdRhO5AcYZ6GHHFtKpS9G1n5vNIpBGLipmKmQ40hQnwfBEK 9YcCx5HGe8T4NG1UPywpqZKblDsiU8Uam6EvTYaei53mUEV7gX/X6QEIMPDVNdTe1RsC lSqUADllCjDlRJ3aqfDHj4gGsZ5WvTndElsOvm3ukXbURNWbOjm9tS3FKy9TW5JIte+s iqchodtdlLO+0839AsHapTHL+am4rmkQFqKuweIuQiuTq0iA/dxkHoEkiJl793SmXbAL d6FIVbXVTWtg6j4nPkHK8I7vb1+rBuBMN5T4ZVmgoa+qulAgS9/S0AV92hnwAdWJS/in gNUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WJLYFFwKJzu0AzBejzceyC93Fh4AhvIk3A/MNZXzKIU=; b=flp6CJ2rztCnGAY8e72/RRZbmp6zg/XjL9vhv6wvN4Ds8lkTpvaXAhgPhY0CcJVoTw NLtUVlXkKMOF+QnS3m43je+5Cmh9uDewwLG9uBJzCW3PEprItk4PVREC70/MqYDmfRVz bGJkwAuk2admWMbIHfL7FcwdAOfcnvR2ec/6Jkp7rCyd8f9wWWutRdDgQ4DLvjUM+cRz vb2AufI3hQqx7WoAf7DlfbRcrX+ptB0CXtyVsN3H1roaqyBqp8opzdFgNfid3tmGPo+S JZyItDRzX/95cvEML9HwaT8Ljp3lAXQDqMWzCSrZhNhLbWipOR/053todwV3dqGSpC/w racg== X-Gm-Message-State: AOAM530rW6rFE2RKhrDuhIUqH6eC9j2xKZyyvB7z3xUJEHM2oLNuQ8Uv qVhvPTTPqSGxs7EU1G5kkiqvAFExy4avjHlWQ0c= X-Google-Smtp-Source: ABdhPJxvT7YhfWN8QbCVz4oydCsKwT/zbXQ5089WXaSZlqzdjbFflulVc086iBmKtewP4KtbC66vp+jW8qrWjcRFTmg= X-Received: by 2002:ac2:5f4d:0:b0:43e:da3e:4529 with SMTP id 13-20020ac25f4d000000b0043eda3e4529mr6768924lfz.627.1649266108188; Wed, 06 Apr 2022 10:28:28 -0700 (PDT) MIME-Version: 1.0 References: <20220406060516.409838-1-hch@lst.de> <20220406060516.409838-24-hch@lst.de> In-Reply-To: <20220406060516.409838-24-hch@lst.de> From: Ryusuke Konishi Date: Thu, 7 Apr 2022 02:28:15 +0900 Message-ID: Subject: Re: [PATCH 23/27] block: add a bdev_max_discard_sectors helper To: Christoph Hellwig Cc: Andreas Gruenbacher , Jens Axboe , device-mapper development , linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-um@lists.infradead.org, linux-block@vger.kernel.org, drbd-dev@lists.linbit.com, nbd@other.debian.org, ceph-devel@vger.kernel.org, virtualization@lists.linux-foundation.org, xen-devel@lists.xenproject.org, linux-bcache@vger.kernel.org, linux-raid@vger.kernel.org, linux-mmc@vger.kernel.org, linux-mtd@lists.infradead.org, linux-nvme@lists.infradead.org, linux-s390@vger.kernel.org, linux-scsi@vger.kernel.org, target-devel@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, cluster-devel@redhat.com, jfs-discussion@lists.sourceforge.net, linux-nilfs , ntfs3@lists.linux.dev, ocfs2-devel@oss.oracle.com, Linux MM X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220406_102832_828134_860CAD03 X-CRM114-Status: GOOD ( 19.37 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org On Wed, Apr 6, 2022 at 11:05 PM Christoph Hellwig wrote: > > Add a helper to query the number of sectors support per each discard bio > based on the block device and use this helper to stop various places from > poking into the request_queue to see if discard is supported and if so how > much. This mirrors what is done e.g. for write zeroes as well. > > Signed-off-by: Christoph Hellwig > --- ... > diff --git a/drivers/target/target_core_device.c b/drivers/target/target_core_device.c > index 16e775bcf4a7c..7d510e4231713 100644 > --- a/drivers/target/target_core_device.c > +++ b/drivers/target/target_core_device.c > @@ -829,9 +829,7 @@ struct se_device *target_alloc_device(struct se_hba *hba, const char *name) > } > > /* > - * Check if the underlying struct block_device request_queue supports > - * the QUEUE_FLAG_DISCARD bit for UNMAP/WRITE_SAME in SCSI + TRIM > - * in ATA and we need to set TPE=1 > + * Check if the underlying struct block_device request_queue supports disard. > */ Here was a typo: s/disard/discard/ On Thu, Apr 7, 2022 at 12:19 AM Andreas Gruenbacher wrote: > If I'm misreading things, could you please document that > bdev_max_discard_sectors() != 0 implies that discard is supported? I got the same impression. Checking the discard support with bdev_max_discard_sectors() != 0 seems a bit unclear than before. Thanks, Ryusuke Konishi ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8B739C433F5 for ; Mon, 11 Apr 2022 06:19:34 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-627-ZRKTT4eFP2iItci9QSrymA-1; Mon, 11 Apr 2022 02:19:32 -0400 X-MC-Unique: ZRKTT4eFP2iItci9QSrymA-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id E5B7885A5BE; Mon, 11 Apr 2022 06:19:25 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id D1485432022; Mon, 11 Apr 2022 06:19:25 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (localhost [IPv6:::1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 75098193F50F; Mon, 11 Apr 2022 06:19:23 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 48C611949763 for ; Wed, 6 Apr 2022 17:28:35 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id 299BE2027EB4; Wed, 6 Apr 2022 17:28:35 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast08.extmail.prod.ext.rdu2.redhat.com [10.11.55.24]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2560C2026614 for ; Wed, 6 Apr 2022 17:28:32 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 2C6A438008A8 for ; Wed, 6 Apr 2022 17:28:32 +0000 (UTC) Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-164-sx-QHAscOmW0tlvyZ46h4A-1; Wed, 06 Apr 2022 13:28:30 -0400 X-MC-Unique: sx-QHAscOmW0tlvyZ46h4A-1 Received: by mail-lf1-f53.google.com with SMTP id y32so5295905lfa.6; Wed, 06 Apr 2022 10:28:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WJLYFFwKJzu0AzBejzceyC93Fh4AhvIk3A/MNZXzKIU=; b=lauQf50QRqgGzSTUPbal207oEU2VY0BTsSXqvEq9HByfGGESDMtuzrfWU8zK7chAAx lx084Ydi1WMXDS/KZ1oUuiL7/6Itz+1MUh0EIzle6Pe1JCIq1r5BU9W30vh8h6U9ovFe nPNkDn4hjbne3Ikm/zDo5dwh+gjAFoe4zR6JZ5rCV9ohgMN+nSsbzmaOIDMgnLPpHA19 t/mX4hr6G41t92nF3qn+dvtnBQS+tMsLeCuqyDUpCNzp2pCISMcX+Vog/SLnkxMro8/W wRzGxoxN1eeA7bN1ts63CMDtVRvshuu1r9EDIYv7hdMdykQ2LdBEXssQgrU2cjhu24EA yHug== X-Gm-Message-State: AOAM531C9mab1nqOh3HydwW7+xux9sV+pdWuHDfw8+rf7twowm4ii45u O43rHjYGWVcTnXLEulVRKsT1/wqGyMli6PXOhQ4= X-Google-Smtp-Source: ABdhPJxvT7YhfWN8QbCVz4oydCsKwT/zbXQ5089WXaSZlqzdjbFflulVc086iBmKtewP4KtbC66vp+jW8qrWjcRFTmg= X-Received: by 2002:ac2:5f4d:0:b0:43e:da3e:4529 with SMTP id 13-20020ac25f4d000000b0043eda3e4529mr6768924lfz.627.1649266108188; Wed, 06 Apr 2022 10:28:28 -0700 (PDT) MIME-Version: 1.0 References: <20220406060516.409838-1-hch@lst.de> <20220406060516.409838-24-hch@lst.de> In-Reply-To: <20220406060516.409838-24-hch@lst.de> From: Ryusuke Konishi Date: Thu, 7 Apr 2022 02:28:15 +0900 Message-ID: To: Christoph Hellwig X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Mailman-Approved-At: Mon, 11 Apr 2022 06:19:21 +0000 Subject: Re: [dm-devel] [PATCH 23/27] block: add a bdev_max_discard_sectors helper X-BeenThere: dm-devel@redhat.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: device-mapper development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: jfs-discussion@lists.sourceforge.net, linux-nvme@lists.infradead.org, virtualization@lists.linux-foundation.org, Linux MM , device-mapper development , target-devel@vger.kernel.org, linux-mtd@lists.infradead.org, drbd-dev@lists.linbit.com, linux-s390@vger.kernel.org, linux-nilfs , Andreas Gruenbacher , linux-scsi@vger.kernel.org, cluster-devel@redhat.com, xen-devel@lists.xenproject.org, linux-ext4@vger.kernel.org, linux-um@lists.infradead.org, nbd@other.debian.org, linux-block@vger.kernel.org, linux-bcache@vger.kernel.org, ceph-devel@vger.kernel.org, Jens Axboe , linux-raid@vger.kernel.org, linux-mmc@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-xfs@vger.kernel.org, ocfs2-devel@oss.oracle.com, linux-fsdevel@vger.kernel.org, ntfs3@lists.linux.dev, linux-btrfs@vger.kernel.org Errors-To: dm-devel-bounces@redhat.com Sender: "dm-devel" X-Scanned-By: MIMEDefang 2.85 on 10.11.54.10 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dm-devel-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Wed, Apr 6, 2022 at 11:05 PM Christoph Hellwig wrote: > > Add a helper to query the number of sectors support per each discard bio > based on the block device and use this helper to stop various places from > poking into the request_queue to see if discard is supported and if so how > much. This mirrors what is done e.g. for write zeroes as well. > > Signed-off-by: Christoph Hellwig > --- ... > diff --git a/drivers/target/target_core_device.c b/drivers/target/target_core_device.c > index 16e775bcf4a7c..7d510e4231713 100644 > --- a/drivers/target/target_core_device.c > +++ b/drivers/target/target_core_device.c > @@ -829,9 +829,7 @@ struct se_device *target_alloc_device(struct se_hba *hba, const char *name) > } > > /* > - * Check if the underlying struct block_device request_queue supports > - * the QUEUE_FLAG_DISCARD bit for UNMAP/WRITE_SAME in SCSI + TRIM > - * in ATA and we need to set TPE=1 > + * Check if the underlying struct block_device request_queue supports disard. > */ Here was a typo: s/disard/discard/ On Thu, Apr 7, 2022 at 12:19 AM Andreas Gruenbacher wrote: > If I'm misreading things, could you please document that > bdev_max_discard_sectors() != 0 implies that discard is supported? I got the same impression. Checking the discard support with bdev_max_discard_sectors() != 0 seems a bit unclear than before. Thanks, Ryusuke Konishi -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 References: <20220406060516.409838-1-hch@lst.de> <20220406060516.409838-24-hch@lst.de> In-Reply-To: <20220406060516.409838-24-hch@lst.de> From: Ryusuke Konishi Date: Thu, 7 Apr 2022 02:28:15 +0900 Message-ID: Subject: Re: [PATCH 23/27] block: add a bdev_max_discard_sectors helper List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-um" Errors-To: linux-um-bounces+geert=linux-m68k.org@lists.infradead.org To: Christoph Hellwig Cc: Andreas Gruenbacher , Jens Axboe , device-mapper development , linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-um@lists.infradead.org, linux-block@vger.kernel.org, drbd-dev@lists.linbit.com, nbd@other.debian.org, ceph-devel@vger.kernel.org, virtualization@lists.linux-foundation.org, xen-devel@lists.xenproject.org, linux-bcache@vger.kernel.org, linux-raid@vger.kernel.org, linux-mmc@vger.kernel.org, linux-mtd@lists.infradead.org, linux-nvme@lists.infradead.org, linux-s390@vger.kernel.org, linux-scsi@vger.kernel.org, target-devel@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, cluster-devel@redhat.com, jfs-discussion@lists.sourceforge.net, linux-nilfs , ntfs3@lists.linux.dev, ocfs2-devel@oss.oracle.com, Linux MM On Wed, Apr 6, 2022 at 11:05 PM Christoph Hellwig wrote: > > Add a helper to query the number of sectors support per each discard bio > based on the block device and use this helper to stop various places from > poking into the request_queue to see if discard is supported and if so how > much. This mirrors what is done e.g. for write zeroes as well. > > Signed-off-by: Christoph Hellwig > --- ... > diff --git a/drivers/target/target_core_device.c b/drivers/target/target_core_device.c > index 16e775bcf4a7c..7d510e4231713 100644 > --- a/drivers/target/target_core_device.c > +++ b/drivers/target/target_core_device.c > @@ -829,9 +829,7 @@ struct se_device *target_alloc_device(struct se_hba *hba, const char *name) > } > > /* > - * Check if the underlying struct block_device request_queue supports > - * the QUEUE_FLAG_DISCARD bit for UNMAP/WRITE_SAME in SCSI + TRIM > - * in ATA and we need to set TPE=1 > + * Check if the underlying struct block_device request_queue supports disard. > */ Here was a typo: s/disard/discard/ On Thu, Apr 7, 2022 at 12:19 AM Andreas Gruenbacher wrote: > If I'm misreading things, could you please document that > bdev_max_discard_sectors() != 0 implies that discard is supported? I got the same impression. Checking the discard support with bdev_max_discard_sectors() != 0 seems a bit unclear than before. Thanks, Ryusuke Konishi _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ryusuke Konishi Date: Thu, 7 Apr 2022 02:28:15 +0900 Subject: [Cluster-devel] [PATCH 23/27] block: add a bdev_max_discard_sectors helper In-Reply-To: <20220406060516.409838-24-hch@lst.de> References: <20220406060516.409838-1-hch@lst.de> <20220406060516.409838-24-hch@lst.de> Message-ID: List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Wed, Apr 6, 2022 at 11:05 PM Christoph Hellwig wrote: > > Add a helper to query the number of sectors support per each discard bio > based on the block device and use this helper to stop various places from > poking into the request_queue to see if discard is supported and if so how > much. This mirrors what is done e.g. for write zeroes as well. > > Signed-off-by: Christoph Hellwig > --- ... > diff --git a/drivers/target/target_core_device.c b/drivers/target/target_core_device.c > index 16e775bcf4a7c..7d510e4231713 100644 > --- a/drivers/target/target_core_device.c > +++ b/drivers/target/target_core_device.c > @@ -829,9 +829,7 @@ struct se_device *target_alloc_device(struct se_hba *hba, const char *name) > } > > /* > - * Check if the underlying struct block_device request_queue supports > - * the QUEUE_FLAG_DISCARD bit for UNMAP/WRITE_SAME in SCSI + TRIM > - * in ATA and we need to set TPE=1 > + * Check if the underlying struct block_device request_queue supports disard. > */ Here was a typo: s/disard/discard/ On Thu, Apr 7, 2022 at 12:19 AM Andreas Gruenbacher wrote: > If I'm misreading things, could you please document that > bdev_max_discard_sectors() != 0 implies that discard is supported? I got the same impression. Checking the discard support with bdev_max_discard_sectors() != 0 seems a bit unclear than before. Thanks, Ryusuke Konishi From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ryusuke Konishi Subject: Re: [PATCH 23/27] block: add a bdev_max_discard_sectors helper Date: Thu, 7 Apr 2022 02:28:15 +0900 Message-ID: References: <20220406060516.409838-1-hch@lst.de> <20220406060516.409838-24-hch@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WJLYFFwKJzu0AzBejzceyC93Fh4AhvIk3A/MNZXzKIU=; b=nHoFYmIVcbUdYBuRBczLdRhO5AcYZ6GHHFtKpS9G1n5vNIpBGLipmKmQ40hQnwfBEK 9YcCx5HGe8T4NG1UPywpqZKblDsiU8Uam6EvTYaei53mUEV7gX/X6QEIMPDVNdTe1RsC lSqUADllCjDlRJ3aqfDHj4gGsZ5WvTndElsOvm3ukXbURNWbOjm9tS3FKy9TW5JIte+s iqchodtdlLO+0839AsHapTHL+am4rmkQFqKuweIuQiuTq0iA/dxkHoEkiJl793SmXbAL d6FIVbXVTWtg6j4nPkHK8I7vb1+rBuBMN5T4ZVmgoa+qulAgS9/S0AV92hnwAdWJS/in gNUw== In-Reply-To: <20220406060516.409838-24-hch-jcswGhMUV9g@public.gmane.org> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: drbd-dev-bounces-cunTk1MwBs8qoQakbn7OcQ@public.gmane.org Errors-To: drbd-dev-bounces-cunTk1MwBs8qoQakbn7OcQ@public.gmane.org To: Christoph Hellwig Cc: jfs-discussion-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, Linux MM , device-mapper development , target-devel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, drbd-dev-cunTk1MwBs8qoQakbn7OcQ@public.gmane.org, linux-s390-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-nilfs , Andreas Gruenbacher , linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, cluster-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, xen-devel-GuqFBffKawtpuQazS67q72D2FQJk+8+b@public.gmane.org, linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-um-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, nbd-2H2hN8V1XRtuHlm7Suoebg@public.gmane.org, linux-block-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-bcache-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, ceph-devel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jens Axboe , linux-raid-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-f2fs-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, linux-xfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, ocfs2-devel-N0ozoZBvEnrZJqsBc5GL+g@public.gmane.org, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, ntfs3-cunTk1MwBs/YUNznpcFYbw@public.gmane.org On Wed, Apr 6, 2022 at 11:05 PM Christoph Hellwig wrote: > > Add a helper to query the number of sectors support per each discard bio > based on the block device and use this helper to stop various places from > poking into the request_queue to see if discard is supported and if so how > much. This mirrors what is done e.g. for write zeroes as well. > > Signed-off-by: Christoph Hellwig > --- ... > diff --git a/drivers/target/target_core_device.c b/drivers/target/target_core_device.c > index 16e775bcf4a7c..7d510e4231713 100644 > --- a/drivers/target/target_core_device.c > +++ b/drivers/target/target_core_device.c > @@ -829,9 +829,7 @@ struct se_device *target_alloc_device(struct se_hba *hba, const char *name) > } > > /* > - * Check if the underlying struct block_device request_queue supports > - * the QUEUE_FLAG_DISCARD bit for UNMAP/WRITE_SAME in SCSI + TRIM > - * in ATA and we need to set TPE=1 > + * Check if the underlying struct block_device request_queue supports disard. > */ Here was a typo: s/disard/discard/ On Thu, Apr 7, 2022 at 12:19 AM Andreas Gruenbacher wrote: > If I'm misreading things, could you please document that > bdev_max_discard_sectors() != 0 implies that discard is supported? I got the same impression. Checking the discard support with bdev_max_discard_sectors() != 0 seems a bit unclear than before. Thanks, Ryusuke Konishi