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.
