Re: [RFC] [PATCHv2 0/5] reiser4: discard support: initial implementation.

[Edward Shishkin <edward.shishkin@gmail.com>]

On 05/06/2014 11:56 AM, Ivan Shapovalov wrote:
> Hi Dušan,
>
> On Tuesday 06 May 2014 at 09:09:12, Dušan Čolić wrote:	
>> What about trim performance penalty? AFAIK all devices that are below
>> SATA3.1 have pretty long time to execute discard command so if we execute
>> discard at every commit time we could make large stalls to the system. Can
>> we batch them
> This is already happening. Other filesystems issue discard requests directly
> when blocks are deallocated, once per each extent. We delay them until a
> transaction is committed, in hope to be able to merge small extents into large
> ones and issue a lesser count of discard requests.


I would also add that discard extents issued by reiser4 are of the best
quality, because we maintain 2 exemplars of bitmap. Allocation always
happens on the base of working bitmap, where discard extents are still
marked as busy. So we don't "spoil" them..

Edward.


> Any penalties remaining with this approach are inherent; if one can't tolerate
> these, they just should not use "realtime" TRIM, i. e. not pass 'discard'
> mount option.
>
> There is other way around: fstrim utility and FITRIM ioctl, which tells
> filesystem to do a "cleaning sweep" and discard every free block at once. This
> is to be implemented shortly.
>

--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html