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