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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
