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  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]
Date:   Wed, 27 May 2020 11:32:02 +0200
From:   Reindl Harald <>
To:     Lukas Czerner <>,
        Wang Shilong <>
Cc:, Wang Shilong <>,
        Shuichi Ihara <>,
        Andreas Dilger <>
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 <>
>> 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

[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