Received-SPF: pass (google.com: domain of linux-ext4+bounces-454-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Fri, 15 Dec 2023 12:11:08 +0100
From: Jan Kara <jack@suse.cz>
To: "yebin (H)" <yebin10@huawei.com>
Cc: Jan Kara <jack@suse.cz>, tytso@mit.edu, adilger.kernel@dilger.ca,
	linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ext4: fix inconsistent between segment fstrim and full
 fstrim
Message-ID: <20231215111108.5xgxhhm4nskq6syh@quack3>
References: <20231214064635.4128391-1-yebin10@huawei.com>
 <20231214085834.svce3mvfnctikwyq@quack3>
 <657AFDE6.1090606@huawei.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <657AFDE6.1090606@huawei.com>

On Thu 14-12-23 21:06:46, yebin (H) wrote:
> 
> 
> On 2023/12/14 16:58, Jan Kara wrote:
> > On Thu 14-12-23 14:46:35, Ye Bin wrote:
> > > There will not issue discard cmd when do segment fstrim for ext4 fs, however,
> > > if full fstrim for the same fs will issue discard cmd.
> > > Above issue may happens as follows:
> > > Precondition:
> > > 1. Fstrim range [0, 15] and [16, 31];
> > > 2. Discard granularity is 16;
> > >              Range1          Range2
> > >        1111000000000000 0000111010101011
> > > There's no free space length large or equal than 16 in 'Range1' or 'Range2'.
> > > As ext4_try_to_trim_range() only search free space among range which user
> > > specified. However, there's maximum free space length 16 in 'Range1'+ 'Range2'.
> > > To solve above issue, we need to find the longest free space to discard.
> > > 
> > > Signed-off-by: Ye Bin <yebin10@huawei.com>
> > OK, I agree that there is this behavioral difference. However is that a
> > practical problem? I mean I would not expect the range to be particularly
> > small, rather something like 1GB and then these boundary conditions don't
> > really matter. This is also sensible so that we can properly track whether
> > the whole block group was trimmed or not. Finally I'd also argue that
> > trimming outside of specified range might be unexpected for the user. So a
> > *fix* for this in my opinion lays in userspace which needs to select
> > sensible ranges to use for trimming.
> > 
> > 								Honza
> Thanks for your reply.
> Our product fstrim entire file system, found to take a long time, thus
> affecting other processes.
> So they want to segment the file system fstrim based on the IO of the
> system. But they found
> that fragmented fstrims didn't work the same as fstrim  for the entire file
> system.
> Users do not know the distribution of free blocks in the file system, and
> they do not know the
> reasonable range. The user's simple perception is that the effect of
> segmented fstrim and full
> fstrim should be consistent.
> I researched the implementation of fstrim on the XFS file system, and for
> the scenario described
> in my patch, the results of both operations are consistent.

OK, we've discussed this on yesterday's ext4 call and we've came to a
conclusion that we don't care that much and consistency among filesystems
is good so I'll go back and review your patch.

								Honza

-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR