linux-kernel - Re: [PATCH] Set the initial TRIM information as TRIMMED

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGpXXZL3CuZj2KmjiYrHNivqesBtVxzq=ZxGHkDPeYVD_tW_Xw@mail.gmail.com>
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/