| 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 linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Thu, 1 Dec 2011 19:50:58 -0500 From: Greg Freemyer <greg.freemyer@...il.com> To: Kyungmin Park <kmpark@...radead.org> Cc: Eric Sandeen <sandeen@...hat.com>, Lukas Czerner <lczerner@...hat.com>, tytso@....edu, tm@....ma, linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH] Set the initial TRIM information as TRIMMED On Thu, Dec 1, 2011 at 7:01 PM, Kyungmin Park <kmpark@...radead.org> wrote: > On 12/2/11, Eric Sandeen <sandeen@...hat.com> wrote: <snip> > Hi, > >> Hm, so if there were freed but un-trimmed blocks at this point, we will >> never trim them until we free _another_ block in the group, right? That >> might be a reasonable tradeoff, but it is somewhat surprising behavior. >> >> i.e. say we do: >> >> mount /mnt >> rm -rf /mnt/very_big_file >> umount /mnt does umount need to force a fitrim if it's available? >> mount /mnt >> fitrim /mnt That way if umount is clean, then the new logic could kick for the next mount, but if there was not a clean umount, then in addition to replaying the journal, the next mount could leave the fitrim info not initialized. I'm sure there are smarter ways to track it. The biggest thing I'm suggesting is for there to at least be a single boolean "fitrim'ed state flag for the whole filesystem. that could cleared on mount and set on a clean umount. Greg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists