Re: SSD TRIM / "discard" works after a remount with mount -a?
On 8 March 2016 at 19:03, Swift Griggswrote: [snip] > >>> 3. dd if=/dev/zero bs=4096k of=/my/affected/file/system/DELETEME.000 >>> I'm assuming short blocks get written as partials. >> >> I would skip this step and the following ones. They likely do more harm >> than good. > > > I'd like to know where you are coming from on that. I get that SSDs have to > be wear leveled, but I'm wondering what's going to happen the next time that > I write to a block that was deleted but not properly trim'd. Wouldn't that > cause a pause / blocking while the TRIM operation had to complete? As I understand it TRIM doesn't actually perform any clearing operations it just tells the SSD that the block(s) in question are free and can be re-used. At the filesystem level the filesystem knows which blocks are free and used, but when it gets to the hardware level this has just decended into 'store this block of data at this location'. In the days of spinning rust this was fine, but as you say modern SSDs require writes to be spread across the flash to reduce wear. TRIM allows the operating system to inform the SSD that a particular block is free, which allows the controller to best track usage and distribute writes. However, if you don't have TRIM enabled then the underlying drive will just 'fill up' until new writes just use old blocks. The steps you outlined would probably ensure the currently used blocks are 'trimmed', however this is done at the expense of a write cycle for all the currently unused blocks. On modern drives this probably makes very little difference to the overall effective life (but hence why it's probably not worth it also). Techreport did a quite interesting torture test, summerised here: http://arstechnica.com/gadgets/2015/03/consumer-ssds-benchmarked-to-death-and-last-far-longer-than-rated/ (tldr; consumer drives generally last much longer than the quoted MTBF, oh, and Samsung 850 PROs are just great!!) Incidentally, the 'refresh' tool Samsung released for the slow performing 840 EVOs essentially does a similar thing, it causes a full rewrite. Cheers, Ian
Re: SSD TRIM / "discard" works after a remount with mount -a?
> I have a scenario where I have several NetBSD systems which were just > upgraded to SSDs. I forgot to turn on discard (TRIM) support on the drives > when I first put them in. I don’t think that’s a big deal. For the record, I have run my SSD without TRIM on NetBSD for a long while now. In fact, your email taught me about the „discard“ option :¬ > 1. Edit /etc/fstab, and add the "discard" option to all FFS file systems OK. > 2. Run "mount -a" which should re-mount the affected file systems with > the newly added option. I'm assuming this work for the trim/discard > opton. Reboot? Otherwise, to enable TRIM without rebooting, try: mount -uo discard / > 3. dd if=/dev/zero bs=4096k of=/my/affected/file/system/DELETEME.000 > I'm assuming short blocks get written as partials. I would skip this step and the following ones. They likely do more harm than good. —Benny.
Re: SSD TRIM / "discard" works after a remount with mount -a?
On Tue, 8 Mar 2016, Benny Siegert wrote: I don?t think that?s a big deal. For the record, I have run my SSD without TRIM on NetBSD for a long while now. In fact, your email taught me about the ?discard? option :? Well, I have also on other systems. I've also read that some SSDs don't actually need TRIM at all. I use Samsung 850 Pros. Otherwise, to enable TRIM without rebooting, try: mount -uo discard / I think that the mount -a does the same thing. What I did to test was to try it on one system and after editing the /etc/fstab and running mount -a I see that "discard" is listed in the "mount" output. However, I'm a little suspicous that it's not actually on. Paranoia. 3. dd if=/dev/zero bs=4096k of=/my/affected/file/system/DELETEME.000 I'm assuming short blocks get written as partials. I would skip this step and the following ones. They likely do more harm than good. I'd like to know where you are coming from on that. I get that SSDs have to be wear leveled, but I'm wondering what's going to happen the next time that I write to a block that was deleted but not properly trim'd. Wouldn't that cause a pause / blocking while the TRIM operation had to complete? Maybe I have a jacked up understanding of the dynamics, but hey, that's why I asked :-) Thanks for the feedback. -Swift