On Thu, Jan 31, 2019 at 05:35:10PM +0200, Nikolay Borisov wrote: > On 31.01.19 г. 17:21 ч., David Sterba wrote: > > On Wed, Jan 30, 2019 at 04:50:48PM +0200, Nikolay Borisov wrote: > >> Up until know trimming the freespace was done irrespective of what the > >> arguments of the FITRIM ioctl were. For example fstrim's -o/-l arguments > >> will be entirely ignored. Fix it by correctly handling those paramter. > >> This requires breaking if the found freespace extent is after the end > >> of the passed range as well as completing trim after trimming > >> fstrim_range::len bytes. > > > > How does this work with with multipe-device filesystems? The fstrim > > range would apply to all of them. Which does make some sense, though > > might be unexpected as this does not happen for other filesystems. > > Well FITRIM doesn't have support for multiple device so it's to the > discretion of the fs how exactly this is implemented. And this is indeed > the way things work currently. > > > The FITRIM range is in the physical coordinates, so eg. the taking the > > maximum size of all devices and iterating over that by 1GiB steps would > > go though the whole filesystem. Something to put to the changelog and > > documentation. > > I don't follow, trimming would just trim the physical range as passed by > fstrim -o/-l options. That 1gb value is not hardcoded anywhere. If > someone wants to trim all of the freespace (which is what the majority > of the user do) then they can run FITRIM with 0 for offset and -1 for > length.
Yeah but I wanted to give an example of usecase when the range is not 0/-1 and how this is could to be used.
