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

[Lukas Czerner]

On Thu, 1 Dec 2011, Greg Freemyer wrote:

> On Thu, Dec 1, 2011 at 7:01 PM, Kyungmin Park <kmpark@xxxxxxxxxxxxx> wrote:
> > On 12/2/11, Eric Sandeen <sandeen@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--