All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Ted Tso <tytso@mit.edu>
Cc: linux-ext4@vger.kernel.org, Jan Kara <jack@suse.cz>,
	Lukas Czerner <lczerner@redhat.com>
Subject: Re: [PATCH] ext4: Avoid trim error on fs with small groups
Date: Fri, 12 Nov 2021 16:26:36 +0100	[thread overview]
Message-ID: <20211112152636.GC25491@quack2.suse.cz> (raw)
In-Reply-To: <20211112152202.26614-1-jack@suse.cz>

On Fri 12-11-21 16:22:02, Jan Kara wrote:
> A user reported FITRIM ioctl failing for him on ext4 on some devices
> without apparent reason.  After some debugging we've found out that
> these devices (being LVM volumes) report rather large discard
> granularity of 42MB and the filesystem had 1k blocksize and thus group
> size of 8MB. Because ext4 FITRIM implementation puts discard
> granularity into minlen, ext4_trim_fs() declared the trim request as
> invalid. However just silently doing nothing seems to be a more
> appropriate reaction to such combination of parameters since user did
> not specify anything wrong.
> 
> CC: Lukas Czerner <lczerner@redhat.com>
> Fixes: 5c2ed62fd447 ("ext4: Adjust minlen with discard_granularity in the FITRIM ioctl")
> Signed-off-by: Jan Kara <jack@suse.cz>
> ---
>  fs/ext4/ioctl.c   | 2 --
>  fs/ext4/mballoc.c | 8 ++++++++
>  2 files changed, 8 insertions(+), 2 deletions(-)

I wanted to add one more comment: Alternatively we could return EOPNOTSUPP
in this case to indicate trim is never going to work on this fs. But just
doing nothing since we cannot submit useful discard request seems
appropriate to me.

								Honza


> 
> diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
> index 606dee9e08a3..220a4c8178b5 100644
> --- a/fs/ext4/ioctl.c
> +++ b/fs/ext4/ioctl.c
> @@ -1117,8 +1117,6 @@ static long __ext4_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
>  		    sizeof(range)))
>  			return -EFAULT;
>  
> -		range.minlen = max((unsigned int)range.minlen,
> -				   q->limits.discard_granularity);
>  		ret = ext4_trim_fs(sb, &range);
>  		if (ret < 0)
>  			return ret;
> diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
> index 72bfac2d6dce..7174add7b153 100644
> --- a/fs/ext4/mballoc.c
> +++ b/fs/ext4/mballoc.c
> @@ -6405,6 +6405,7 @@ ext4_trim_all_free(struct super_block *sb, ext4_group_t group,
>   */
>  int ext4_trim_fs(struct super_block *sb, struct fstrim_range *range)
>  {
> +	struct request_queue *q = bdev_get_queue(sb->s_bdev);
>  	struct ext4_group_info *grp;
>  	ext4_group_t group, first_group, last_group;
>  	ext4_grpblk_t cnt = 0, first_cluster, last_cluster;
> @@ -6423,6 +6424,13 @@ int ext4_trim_fs(struct super_block *sb, struct fstrim_range *range)
>  	    start >= max_blks ||
>  	    range->len < sb->s_blocksize)
>  		return -EINVAL;
> +	/* No point to try to trim less than discard granularity */
> +	if (range->minlen < q->limits.discard_granularity) {
> +		minlen = EXT4_NUM_B2C(EXT4_SB(sb),
> +			q->limits.discard_granularity >> sb->s_blocksize_bits);
> +		if (minlen > EXT4_CLUSTERS_PER_GROUP(sb))
> +			goto out;
> +	}
>  	if (end >= max_blks)
>  		end = max_blks - 1;
>  	if (end <= first_data_blk)
> -- 
> 2.26.2
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

  reply	other threads:[~2021-11-12 15:26 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-12 15:22 [PATCH] ext4: Avoid trim error on fs with small groups Jan Kara
2021-11-12 15:26 ` Jan Kara [this message]
2021-11-15 11:48 ` Lukas Czerner
     [not found]   ` <20211115125141.GD23412@quack2.suse.cz>
     [not found]     ` <59b60aae9401a043f7d7cec0f8004f2ca7d4f4db.camel@suse.com>
     [not found]       ` <20211115145312.g4ptf22rl55jf37l@work>
     [not found]         ` <4e4d1ac7735c38f1395db19b97025bf411982b60.camel@suse.com>
2021-11-16 11:56           ` Lukas Czerner
2021-11-17  4:35             ` Martin K. Petersen
2021-11-19 15:43               ` Martin Wilck
2021-11-22 13:53                 ` Lukas Czerner
2022-01-03 15:34                   ` Martin Wilck
2022-01-03 18:59                     ` Lukas Czerner
2022-01-04 14:55                       ` Jan Kara
2022-01-04 15:05                         ` Martin Wilck
2022-01-05  3:14 ` Theodore Ts'o

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211112152636.GC25491@quack2.suse.cz \
    --to=jack@suse.cz \
    --cc=lczerner@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.