On Thu, Jan 1, 2015 at 6:10 AM, Rodney Baker
wrote: The disk is a Samsung 850 PRO and Samsung actually provide a native linux CLI tool for management. They do say, though, that (for their tool) trim is only supported for ext4. I understand that other filesystems have native trim support built in, but I'm most comfortable with ext3/ext4 at this point in time anyway (although I do use xfs on at least one data storage
On Fri, 2 Jan 2015 17:35:43 Greg Freemyer wrote: partition).
Beware of filesystem's with built in trim.
Basically if you pass in an argument at mount time, you are engaging realtime trim.
If you have to schedule a nightly (or weekly) trim command, then it is batched trim.
== Batched trim is basically safe and a performance benefit for any SSD.
Realtime trim is a different matter. For almost all SSDs sold (or designed) in 2013 or before, it is a performance hit. Newer SSDs support asynchronous trim. That is the feature need to have before realtime trim is a net benefit.
For me, I still stick to batched mode exclusively.
FYI: Windows runs batched mode only as far as I know, so realtime trim has not been an important feature for SSD manufacturers.
Greg -- Greg Freemyer
Thanks again for everone's input. Successful migration completed a few days ago with no real problems (a couple of minor fights with grub2 to stop it mounting the old / from the soon-to-be-decommissioned hdd instead of from the new ssd...). Boot times and program load times are dramatically improved. :) Tonight I've made some more changes, converting 2x 1TB RAID 1 arrays (one held /home, the other a data storage partition) into 2x 1TB RAID 10 arrays, with a corresponding improvement in read/write speed for /home (noticeably speeding up KDE4 startup times as well). Not as big a jump as an SSD, but redundancy plus improved I/O performance is a plus in my book. :) All of this just goes to prove that you can throw fast processors and lots of RAM at the system (16GB in my case), but then the performance limiting factor becomes the disk I/O system. A lot of processes on oS13.1/KDE4 seem to be I/O bound (probably due to the modularity achieved through lots of dependencies on shared libraries). Still - it's finally feeling like it's getting closer to it's performance potential. Once 2TB SSD prices come down a bit more, I'll have to replace some more HDD's with SSD's. Regards to all, Rodney. -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au ============================================================== -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org