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. 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. -- Ivan Shapovalov / intelfx / > or make the discard period configurable through mount option? > > http://en.wikipedia.org/wiki/Trim_(computing)#Shortcomings > > On Tue, May 6, 2014 at 7:30 AM, Ivan Shapovalov <intelfx100@xxxxxxxxx>wrote: > > [...]
Attachment:
signature.asc
Description: This is a digitally signed message part.
