Re: fstrim is takes a long time on Btrfs and NVMe

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Dec 22, 2019 at 11:06 AM Nikolay Borisov <nborisov@xxxxxxxx> wrote:
>
> Well, if we rework how fitrim is implemented - e.g. make discards async
> and have some sort of locking to exclude queued extents being allocated
> we can alleviate the problem somewhat.

Is it really helpful to fitrim every single lone 4K block? That's one
extreme. The other extreme is only issuing FITRIM to (Btrfs)
unallocated space, missing a bunch of unused space in block groups. Is
there some happy compromise? How about filtering for a minimum
contiguous range of 1MiB?

And leave online discards for the single lonely 4k block case, with
devices that use queued trim?

My understanding is that any SSD that's suitably well over provisioned
for its intended workload, doesn't need unused block hinting of any
kind. It's really the devices that can exhaust their reserve of erased
cells, resulting in writes that are dog slow, that can effectively
take advantage of trim. But does this class of device really benefit
from every possible unused block being reported by trim to the
firmware? Or is there some sane minimum size, bigger than 4K, that
would be useful to report, and also a lot faster to report?



-- 
Chris Murphy



[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux