Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Andreas Dilger <adilger@dilger.ca>
Mime-Version: 1.0 (1.0)
Subject: Re: How to force EXT4_MB_GRP_CLEAR_TRIMMED on a live ext4?
Date:   Mon, 25 Oct 2021 10:47:46 -0600
Message-Id: <97FC9914-F57C-4D96-8C24-5B6AE7C6FE71@dilger.ca>
References: <1635175743.26818.15.camel@guerby.net>
Cc:     Lukas Czerner <lczerner@redhat.com>, linux-ext4@vger.kernel.org
In-Reply-To: <1635175743.26818.15.camel@guerby.net>
To:     Laurent GUERBY <laurent@guerby.net>
Precedence: bulk

On Oct 25, 2021, at 09:29, Laurent GUERBY <laurent@guerby.net> wrote:
>=20
> =EF=BB=BFOn Mon, 2021-10-25 at 11:42 +0200, Lukas Czerner wrote:
>>> On Sat, Oct 23, 2021 at 12:24:40PM +0200, Laurent GUERBY wrote:
>>>=20
>>> I did end up creating dummy files to fill the filesystem and then
>>> removing them, but this is far less efficient than what a
>>> filesystem
>>> tool could do.
>>=20
>> Yeah, that's bad. The information is stored in the buddy cache in
>> memory
>> and AFAIK is only dropped on unmount. I'll have to think about how to
>> clear either the cache or selectively just the flag.
>>=20
>> What would be more convenient way of doing this for you, -o remount,
>> or
>> using let's say tune2fs ? I am not promising anything yet, but I'll
>> think
>> about how to implement it.
>>=20
>>=20
>> Meanwhile other than umount/mount, or actually writing to the dummy
>> files,
>> you can try to use fallocate to allocate all the remaining space in
>> the
>> file system and subsequently removing it. That should be more
>> efficient,
>> but don't forget to sync after remove to make sure the space is
>> released
>> before you call fstrim.
>=20
> Thanks for the advice on fallocate! It does work and is very fast.

It would be enough to allocate and free a block in each group (128MB)
of the filesystem. That can't be controlled directly by fallocate(),
but indirectly via the "goal inode", but if fallocate() if all free space is=
 fast
enough it may not be worth the effort.=20

> I would prefer a specific tune2fs as remount forcing this TRIM cache
> clearing behaviour might be unwanted.
>=20
>> You could also force fsck on ro file system and use -E discard to
>> trim the
>> free space but I can't say I recommend it.

This would have a danger to corrupt the mounted filesystem, so should
not be allowed when doing a read-only e2fsck. The bitmaps that e2fsck
is using for the trim may be stale if the filesystem is modified since the
start of the run, which may be a long time in some cases (minutes, hours).

Cheers, Andreas=