[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <520b260b-13e9-4c62-eaeb-c44215b14089@thelounge.net>
Date: Wed, 27 May 2020 11:32:02 +0200
From: Reindl Harald <h.reindl@...lounge.net>
To: Lukas Czerner <lczerner@...hat.com>,
Wang Shilong <wangshilong1991@...il.com>
Cc: linux-ext4@...r.kernel.org, Wang Shilong <wshilong@....com>,
Shuichi Ihara <sihara@....com>,
Andreas Dilger <adilger@...ger.ca>
Subject: Re: [PATCH] ext4: introduce EXT4_BG_WAS_TRIMMED to optimize trim
Am 27.05.20 um 11:19 schrieb Lukas Czerner:
> On Wed, May 27, 2020 at 04:38:50PM +0900, Wang Shilong wrote:
>> From: Wang Shilong <wshilong@....com>
>>
>> Currently WAS_TRIMMED flag is not persistent, whenever filesystem was
>> remounted, fstrim need walk all block groups again, the problem with
>> this is FSTRIM could be slow on very large LUN SSD based filesystem.
>>
>> To avoid this kind of problem, we introduce a block group flag
>> EXT4_BG_WAS_TRIMMED, the side effect of this is we need introduce
>> extra one block group dirty write after trimming block group.
would that also fix the issue that *way too much* is trimmed all the
time, no matter if it's a thin provisioned vmware disk or a phyiscal
RAID10 with SSD
no way of 315 MB deletes within 2 hours or so on a system with just 485M
used
[root@...ewall:~]$ fstrim -av
/boot: 0 B (0 bytes) trimmed on /dev/sda1
/: 315.2 MiB (330522624 bytes) trimmed on /dev/sdb1
[root@...ewall:~]$ df
Filesystem Type Size Used Avail Use% Mounted on
/dev/sdb1 ext4 5.8G 463M 5.4G 8% /
/dev/sda1 ext4 485M 42M 440M 9% /boot
Powered by blists - more mailing lists