On 04/09/14 20:07, Rich Freeman wrote: > On Thu, Sep 4, 2014 at 2:26 PM, Сергей <protsero...@gmail.com> wrote: >> You need to run Fstrim if you mounted your partition WITHOUT "discard" >> option and did lots of changes. For example, if you installed your >> system without "discard", do fstrim and then add "discard" to >> /etc/fstab. >> > Just a note that depending on the SSD model, discard can have a > substantial performance penalty with negligible benefit compared to > just sticking fstrim in your crontab. +1 also for lvm remember to add in lvm.conf issue_discards = 1
> > In theory the ssd should just handle discard by making a note of what > is trimmed and utlizing this information when needed. In practice > many ssds handle a trim by dropping whatever they're doing and don't a > copy/delete cycle if only part of a block is trimmed, which defeats > the whole point of trimming in the first place. FStrim has the > advantage of being more asynchronous and possibly being able to > consolidate trims over a longer time-period, which could improve > performance if the ssd isn't smart about it. i understand that part of the reason it blocks so hard when run and hasn't been run is the ssd defrags/consolidates the used blocks too. it would be nice to know for sure what it's doing, or from kernel-space tell the ssd what is most likely to be changing and what can be consolidated happily. > > Is there a really good place to go for SSD reviews/etc that actually > takes this sort of thing into account? After getting an SSD it became > apparently that they vary widely in terms of quality. Heck, I can't > even tell you what the erase cycle count is from the SMART info, while > other models seems to provide all kinds of useful info. +1 for this as other factors such as the erase blocksize should be taken into account. i.e. the larger the erase blocksize the more need there is for fstrim in the first place, but also the filesystem/partition alignment becomes a magical dark art. > > -- > Rich >
