On Thu, Apr 27, 2017 at 10:50:02AM -0500, Eric Sandeen wrote:
> On 4/27/17 10:46 AM, Eric Sandeen wrote:
> > On 4/27/17 10:38 AM, Darrick J. Wong wrote:
> >> On Thu, Apr 27, 2017 at 09:34:04AM -0500, Eric Sandeen wrote:
> >>> On 4/27/17 3:39 AM, Lukas Czerner wrote:
> >>>> fstrim can take really long time on big, slow device or on file system
> >>>> with a lots of allocation groups. Currently there is no way for the user
> >>>> to cancell the operation. This patch makes it possible for the user to
> >>>> kill fstrim pocess by adding the check for fatal_signal_pending() in
> >>>> xfs_trim_extents().
> >>>
> >>> With this patch, it seems that if it is killed, then nothing is copied
> >>> back to the user about the number of blocks trimmed before the kill.
> >>>
> >>> Is that intentional?
> >>>
> >>> I think it could be done in a way that the progress until the kill
> >>> does get reported, and that might be more useful?
> >>
> >> AFAICT ext4 doesn't report anything if somoene ERESTARTSYS's it...
> >
> > Well we aren't ext4, are we? ;)
> >
> > actually, it seems that it may report "count" as ERESTARTSYS in:
> >
> > ext4_debug("trimmed %d blocks in the group %d\n",
> > count, group);
> >
> > But yeah, although it does update the &range values, they don't
> > get copied out on any error.
> >
> > Anyway, ok, ext4 doesn't. Is there a reason that we shouldn't?
>
> Ok I am probably misunderstanding how things work, maybe it's
> not actually possible (he says after a little experimentation.)
> Feel free to ignore me on this one. :)
>
> -Eric
Hi Eric,
I agree with Darrick, at the moment fstrim is not sticikng around to
care, I am not even sure if it can stick around to care.
Thanks!
-Lukas
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
