linux-ext4 - 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: <alpine.LFD.2.00.1112051117540.4911@dhcp-27-109.brq.redhat.com>
Date:	Mon, 5 Dec 2011 11:25:38 +0100 (CET)
From:	Lukas Czerner <lczerner@...hat.com>
To:	Greg Freemyer <greg.freemyer@...il.com>
cc:	Kyungmin Park <kmpark@...radead.org>,
	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, 1 Dec 2011, Greg Freemyer wrote:

> 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?

Please, do not. That will be weird, unexpected and also annoying,
because fitrim can take a bit longer depending on the hadrware. So I do
not thing doing fitrim at mount/umount time is a good idea.

> 
> >> 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.

The flag makes some sense (if we really need some mechanism like that).
But rather than setting it on (mount/umount) time we should set it after
the fitrim and clear it after the unlink.

Thanks!
-Lukas

> 
> Greg
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--