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