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
--
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
