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-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
