[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <17F9C9F8-9800-4455-9033-1A7FD712E828@dilger.ca>
Date: Thu, 25 Feb 2021 21:42:54 -0700
From: Andreas Dilger <adilger@...ger.ca>
To: harshad shirwadkar <harshadshirwadkar@...il.com>
Cc: Благодаренко Артём
<artem.blagodarenko@...il.com>,
Ext4 Developers List <linux-ext4@...r.kernel.org>,
"Theodore Y. Ts'o" <tytso@....edu>,
Alex Zhuravlev <bzzz@...mcloud.com>,
Shuichi Ihara <sihara@....com>
Subject: Re: [PATCH v2 4/5] ext4: improve cr 0 / cr 1 group scanning
On Feb 25, 2021, at 9:06 PM, harshad shirwadkar <harshadshirwadkar@...il.com> wrote:
>
> Hi Andreas,
>
> On Thu, Feb 25, 2021 at 7:43 PM Andreas Dilger <adilger@...ger.ca> wrote:
>>
>> Yes, modulo using the existing "mb_min_to_scan" parameter for this.
>> I think 4 or 8 or 10 groups is reasonable (512MB, 1GB, 1.25GB),
>> since if it needs a seek anyway then we may as well find a good
>> group for this.
> If I understand it right, the meaning of mb_min_to_scan is the number
> of *extents* that the allocator should try to find before choosing the
> best one. However, what we want here is the number of *groups* that
> the allocator should travel linearly before trying to optimize the
> search. So, even if mb_min_to_scan is set to 1, by the current
> definition of it, it means that the allocator may still traverse the
> entire file system if it doesn't find a match. Is my understanding
> right?
Sorry, you are right. It is the number of extents to scan and not
the number of groups.
Cheers, Andreas
Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)
Powered by blists - more mailing lists