[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1635175743.26818.15.camel@guerby.net>
Date: Mon, 25 Oct 2021 17:29:03 +0200
From: Laurent GUERBY <laurent@...rby.net>
To: Lukas Czerner <lczerner@...hat.com>
Cc: linux-ext4@...r.kernel.org
Subject: Re: How to force EXT4_MB_GRP_CLEAR_TRIMMED on a live ext4?
On Mon, 2021-10-25 at 11:42 +0200, Lukas Czerner wrote:
> On Sat, Oct 23, 2021 at 12:24:40PM +0200, Laurent GUERBY wrote:
> >
> > 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.
>
> 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.
>
> 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.
>
>
> 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.
Thanks for the advice on fallocate! It does work and is very fast.
I would prefer a specific tune2fs as remount forcing this TRIM cache
clearing behaviour might be unwanted.
> 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.
Thanks again for your help,
Sincerely,
Laurent
Powered by blists - more mailing lists