lists.openwall.net | 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
| ||
|
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