On Tue, Oct 15, 2019 at 01:38:25AM +0200, David Sterba wrote: > On Mon, Oct 14, 2019 at 04:17:46PM -0400, Dennis Zhou wrote: > > On Thu, Oct 10, 2019 at 01:11:38PM -0400, Josef Bacik wrote: > > > On Mon, Oct 07, 2019 at 04:17:46PM -0400, Dennis Zhou wrote: > > > > Async discard doesn't remember the discard state of a block_group when > > > > unmounting or when we crash. So, any block_group that is not fully used > > > > may have undiscarded regions. However, free space caches are read in on > > > > demand. Let the discard worker read in the free space cache so we can > > > > proceed with discarding rather than wait for the block_group to be used. > > > > This prevents us from indefinitely deferring discards until that > > > > particular block_group is reused. > > > > > > > > Signed-off-by: Dennis Zhou <den...@kernel.org> > > > > > > What if we did completely discard the last time, now we're going back and > > > discarding again? I think by default we just assume we discarded > > > everything. > > > If we didn't then the user can always initiate a fitrim later. Drop this > > > one. > > > Thanks, > > > > > > > Yeah this is something I wasn't sure about. > > > > It makes me a little uncomfortable to make the lack of persistence a > > user problem. If in some extreme case where someone frees a large amount > > of space and then unmounts. > > Based on past experience, umount should not be slowed down unless really > necessary. > > > We can either make them wait on unmount to > > discard everything or retrim the whole drive which in an ideal world > > should just be a noop on already free lba space. > > Without persistence of the state, we can't make it perfect and I think, > without any hard evidence, that trimming already trimmed blocks is no-op > on the device. We all know that we don't know what SSDs actually do, so > it's best effort and making it "device problem" is a good solution from > filesystem POV.
That makes sense and sounds good to me. I've dropped this patch. Thanks, Dennis
