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

[Greg Freemyer]

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?

>> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/