Message ID | 20230308011807.411478-1-chao@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp79489wrd; Tue, 7 Mar 2023 18:00:26 -0800 (PST) X-Google-Smtp-Source: AK7set+JAvCT8xYdFc/MulGSTMzOmyZVPV7LYIDW3VkVJqaphLs3wsn9a1k6MA7ISIJB3be2gSUK X-Received: by 2002:a05:6a20:2448:b0:cc:c3f7:916b with SMTP id t8-20020a056a20244800b000ccc3f7916bmr15830006pzc.0.1678240826617; Tue, 07 Mar 2023 18:00:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1678240826; cv=none; d=google.com; s=arc-20160816; b=zPrEKLQY7ECiRWV2CkSbS/mP7evW2hmcQHuuykc17cUwJoLNwoU9MdKdTzghSFnmTk oHDT3RQ4Y0EK1yb7+KaFnSphEk/qAzKEOmrSvspO0QXwcPuYPGFGAzXuy0Po4kOUsWuB +70hfLBwsNPVC5IRe3NwW1fEdMfstY89XIAsYIWQ5ZKpSsl3hv1esUa/LkQAy7+kHpMO 5knxY7ffGR5petK0AUe5qFty7rFwxgk8uMkEbqw55sl2d0zNCqumA5SvJ+Qm0JMonQ6+ W7kcOyvqhqam4a19s1c0IrYcZHTUqFZRhU+YpA5LHBGLupTyY+lZxkPw3vy0JMGEkVos S5Ag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=o4wGb515ces7ZNCQdcjCsjWclK/K8E/oxNcz0AXeXdU=; b=HFLbX009oondDOEHhz5MUAiid2/2MJ2AvXcV+r8iR12D/mNemyYTMLFL3p2+38CgEb HtVr/SnLfwDalYYxxwRvSoHJnT1AN3DayYpuupCWp8+rGAM4fGkiGcyiDpT3v108PcBi uIdVCsgj6QS6uhWU+DHjUcueTMk+owFM/5NfogbetvourVmMqAT0/vG9FO3idiTZQIov 0jG9GxNtx+xzceJSYtrpdU0bj2gfHbMEQQE00WqzoCnSd4OzNkaWbWcW8rdOkdf1NqyI 8dxPexe1UIcAv5uXgqyKHTC3kJDjV4+aHD6HqLYcrmWQ6OsklpqRLrBNlX4kOjxCLwSi wgKQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=vBqtIc2D; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e68-20020a636947000000b004fb1d903b3csi14209060pgc.37.2023.03.07.18.00.13; Tue, 07 Mar 2023 18:00:26 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=vBqtIc2D; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229994AbjCHBS4 (ORCPT <rfc822;toshivichauhan@gmail.com> + 99 others); Tue, 7 Mar 2023 20:18:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58986 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229808AbjCHBSz (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 7 Mar 2023 20:18:55 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3B66827D5D; Tue, 7 Mar 2023 17:18:54 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id E2A74B81B4F; Wed, 8 Mar 2023 01:18:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 45E29C433D2; Wed, 8 Mar 2023 01:18:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1678238331; bh=2NmP/pkRo9go4O+zCA7/qKRxq8rwrCPelZOe2MuMEGs=; h=From:To:Cc:Subject:Date:From; b=vBqtIc2DVqTgPrqbfXobMPXj8RPeKNRlqjg0XgytMQ0MrFy18E+2tDo8nig0aqaYv 8wLj97E6+RUJjzUz30U9aHXrzEb5HYJd+FUzDPq/ZGSUq8V2nf0VaOgBDy7xrub41/ J1aUV2mj9/w6xZYL/7YqoQM7wfGVbObW9E6/ruqbzERYwhcp2MWVutsKz1FPsZL3+t w2b1cG3WB8F7oDVpfttf/NtTULr6gs0Nig7bVQRmXce3AbOwQmU8DuQA1nysiFSBIL gLFIAulfPbKEgbOkGF8hh9WKnacszewvbalgXrSl996x0SrGgI3L3EfbUVUPoKijZl dYGwiSWHv39Bg== From: Chao Yu <chao@kernel.org> To: tytso@mit.edu, adilger.kernel@dilger.ca Cc: linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, Chao Yu <chao@kernel.org> Subject: [PATCH] ext4: fix to report fstrim.minlen back to userspace Date: Wed, 8 Mar 2023 09:18:07 +0800 Message-Id: <20230308011807.411478-1-chao@kernel.org> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1759763053165331906?= X-GMAIL-MSGID: =?utf-8?q?1759763053165331906?= |
Series |
ext4: fix to report fstrim.minlen back to userspace
|
|
Commit Message
Chao Yu
March 8, 2023, 1:18 a.m. UTC
Quoted from manual of fstrim:
"-m, --minimum minimum-size
..., if it's smaller than the device's minimum, and report that
(fstrim_range.minlen) back to userspace."
So this patch tries to report adjusted fstrim_range.minlen back to
userspace via FITRIM interface, if the value is smaller than device's
minimum discard granularity.
Signed-off-by: Chao Yu <chao@kernel.org>
---
fs/ext4/mballoc.c | 3 +++
1 file changed, 3 insertions(+)
Comments
On Wed, Mar 08, 2023 at 09:18:07AM +0800, Chao Yu wrote: > Quoted from manual of fstrim: > > "-m, --minimum minimum-size > ..., if it's smaller than the device's minimum, and report that > (fstrim_range.minlen) back to userspace." First of all, I'll note that the fstrim(8) man page, which is describing how the userspace fstrim application work, is a really weird place to put information about how the fstrim _ioctl_ works. I've added Lukas, who is listed as one of the authors of fstrim, and who probably had a hand in writing the man page. The text in that paragraph describing -m is extremely confusing, and probably needs to be rewritten, and factored out into a fstrim(8) for system adminsitrators, and ioctl_fitrim(2) which documents the the ioctl. > diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c > index 5b2ae37a8b80..bd3ef29cf8a6 100644 > --- a/fs/ext4/mballoc.c > +++ b/fs/ext4/mballoc.c > @@ -6491,6 +6491,9 @@ int ext4_trim_fs(struct super_block *sb, struct fstrim_range *range) > discard_granularity >> sb->s_blocksize_bits); > if (minlen > EXT4_CLUSTERS_PER_GROUP(sb)) > goto out; > + > + /* Report adjusted minlen back to userspace */ > + range->minlen = minlen; > } Unfortunately, this patch is not correct. The units of struct fstrim_range's minlen (here, range->minlen) is bytes. However the minlen variable in ext4_trim_fs is in units of *clusters*. And so it gets rounded up two places. The first time is when it is converted into units of a cluster: minlen = EXT4_NUM_B2C(EXT4_SB(sb), range->minlen >> sb->s_blocksize_bits); And the second time is when it is rounded up to the block device's discard granularity. So after that if statement, we need to convert minlen from clusters to bytes, like so: range->minlen = EXT4_C2B(EXT4_SB(sb), minlen) << sb->s_blocksize_bits); Oh, and by the way, that first conversion is not correct as currently written in ext4_fs_trim(). It should be minlen = (range->minlen + EXT4_CLUSTER_SIZE(sb) - 1) >> (sb->s_blocksize_bits + EXT4_CLUSTER_BITS(sb)); The explanation of why minlen = EXT4_NUM_B2C(EXT4_SB(sb), range->minlen >> sb->s_blocksize_bits); is wrong is left as an exercise to the reader. (Hint: what is supposed to happen if a value of 1 byte is passed in fstrim_range.minlen?) Cheers, - Ted
On 2023/3/11 11:18, Theodore Ts'o wrote: > Unfortunately, this patch is not correct. The units of struct > fstrim_range's minlen (here, range->minlen) is bytes. Oh, that's right, sorry for the mistake. > > However the minlen variable in ext4_trim_fs is in units of *clusters*. > And so it gets rounded up two places. The first time is when it is > converted into units of a cluster: > > minlen = EXT4_NUM_B2C(EXT4_SB(sb), > range->minlen >> sb->s_blocksize_bits); IIUC, if range->minlen is smaller than block size of ext4, above calculation may return a wrong value, due to it looks EXT4_NUM_B2C() expects a non-zero in-parameter. So it needs to round up minlen to block size first and then round up block size to cluster size: minlen = EXT4_NUM_B2C(EXT4_SB(sb), EXT4_BLOCK_ALIGN(range->minlen, sb->s_blocksize_bits)); Or do the conversion at a time as you reminded: minlen = (range->minlen + EXT4_CLUSTER_SIZE(sb) - 1) >> (sb->s_blocksize_bits + EXT4_CLUSTER_BITS(sb)); > > And the second time is when it is rounded up to the block device's > discard granularity. > > So after that if statement, we need to convert minlen from clusters to > bytes, like so: > > range->minlen = EXT4_C2B(EXT4_SB(sb), minlen) << sb->s_blocksize_bits); Thanks for the detailed explanation and reminder. :) Thanks,
diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c index 5b2ae37a8b80..bd3ef29cf8a6 100644 --- a/fs/ext4/mballoc.c +++ b/fs/ext4/mballoc.c @@ -6491,6 +6491,9 @@ int ext4_trim_fs(struct super_block *sb, struct fstrim_range *range) discard_granularity >> sb->s_blocksize_bits); if (minlen > EXT4_CLUSTERS_PER_GROUP(sb)) goto out; + + /* Report adjusted minlen back to userspace */ + range->minlen = minlen; } if (end >= max_blks - 1) { end = max_blks - 1;