linux-kernel - Re: [PATCH] ext4: fix inconsistent between segment fstrim and full fstrim

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20231215111108.5xgxhhm4nskq6syh@quack3>
Date: Fri, 15 Dec 2023 12:11:08 +0100
From: Jan Kara <jack@...e.cz>
To: "yebin (H)" <yebin10@...wei.com>
Cc: Jan Kara <jack@...e.cz>, tytso@....edu, adilger.kernel@...ger.ca,
	linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ext4: fix inconsistent between segment fstrim and full
 fstrim

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@...wei.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@...e.com>
SUSE Labs, CR