Gener Badenas <gener.ong.bade...@gmail.com> wrote: > On Mon, Nov 23, 2015 at 7:54 PM, Sven Hartge <s...@svenhartge.de> wrote: >> Gener Badenas <gener.ong.bade...@gmail.com> wrote:
>> > I am currently using Ubuntu as my operating system. I have an Asus >> > laptop where I replaced the disk with an SSD one for performance. I >> > read before that I need to do fstrim regularly so that performance >> > will not degrade. >> >> > I am currently planning to try Debian Jessie in the near future. If >> > I switch to Debian, do I need to still have a batch cron job to do >> > the fstrim regularly? Or is newer version of the OS can handle >> > that out of the box? >> >> Either you add "discard" as a mount option to your fstab or you crate >> a cronjob to run "fstrim -a -v". >> > Thank you, I will try the discard on fstab. It's new to me and seems > cleaner Caution: There are several SSDs which have problems with queued TRIM, most notably all Samsung 8xx (non-Evo, Evo and Pro) SSDs. Newer kernels will only use a non-queued TRIM for this SSDs so your data is safe, but this comes at a (sometimes significant) performance cost, because the queue has to be flushed before a TRIM can be safely sent. If there are many small delete operations (for example during a kernel build, where many small temporary files are created and deleted shortly after) then the need to flush all commands out if the queue before sending a TRIM will drastically reduce the amount IOPS the SSD will handle. So if you use any of the following devices or devices with the following chipsets, you better use a weekly cronjob: Micron_M500_* Crucial_CT*M500* Micron_M5[15]0_* Crucial_CT*M550* Crucial_CT*MX100* Samsung SSD 8* FCCT*M500* The current list is inside libata-core.c from the Linux kernel code: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/ata/libata-core.c#n4220 Grüße, Sven. -- Sigmentation fault. Core dumped.
