Hey folks, back with another question! I recently saw a thread here where someone was asking about SSD's, which brought my attention to some important issues with SSD systems, such as TRIM commands, alignment, etc.

After doing some research, it seems the best way is just to run fstrim manually from time to time, which I don't mind.

My / and swap partitions are inside an LVM, which is in turn inside of a LUKS container. I can boot from the Slackware disc, manually decrypt the container using the --allow-discards option, activate the LVM, and mount the / partition to run fstrim, no problems and looks like it works ok.

However, I can't seem to figure out how to do this for swap. I did a little more research, and it appears that it is not possible to manually mount swap, but fstrim will only work on a mounted filesystem.

So my question is...is this even possible? Can swap be mounted in some clever way to allow fstrim to work? Do I have to just accept that fstrim cannot be used on a swap partition, and that the area of the SSD containing swap may wear out first? Is it even an issue that I need to be concerned with?

You probably don't need to run fstrim at all. You should have discard as a mount option for your swap space. Check your fstab, if its not present just put a comma after defaults on the line and then the word discard ie: defaults,discard. That should take care of things as additional swap space gets allocated than freed. Your SSD ware-levels over the entire disk as the controller is not aware of the partition tables; and presents a map of blocks to the operation system that in most cases only it knows how map onto the physical memory cells. So you don't need to worry about part of the disk getting worn out first.

With recent(recent being 3.2.x or newer)kernels if you are using ext4 you can mount it with the discard option as well and you really should never need to run fstrim at all. The exception being when you have been using the filesystem without the discard mount option. Some corners of the web claim discard is a performance hit; it may be a small one but unless your work load is really unusual you won't notice.

Yes, I've seen numerous places that talked about using the discard option in fstab, and I even experimented with it for a bit. But, I've also seen several places that said doing it that way wasn't considered a best practice, and that it was better to run it manually. Essentially what I took away from my research was that there's still a lot of debate about what is the best way to administer a system running on an SSD, and there is no clear "correct way" as of yet.

So, what do you do when you have lots of contradicting information? I generally take the more cautious approach, which in this case would be to just run it by hand occasionally...I was thinking maybe once a month would probably be reasonable.

In regards to this statement, if I'm understanding you correctly, is that the disk controller automatically reads/writes to cells across the entire disk, regardless of where the partition tables are? I was under the impression that an SSD was similar to a traditional drive in that read/writes can be spread out within a partition, but not across the entire drive?

Well, I do run ext4 within my root partition, but swap has it's own "swap" filesystem. I suppose I could try just using the discard option for swap in fstab, but I'll have to figure out how to test it (hadn't quite gotten that far yet.)

Indeed, I have read this on numerous sites; I figured it probably wouldn't be noticeable, but I thought I'd go ahead and take the time to figure it out just so I would understand the whole thing better. Especially since there seem to be a lot of differing opinions, which makes it harder to get a solid answer.

I'll try simply mounting swap with the discard option in fstab, and see if I can confirm whether or not it works, and report back with my findings.

Well I have an update on this one.

I discovered that in order to test whether or not TRIM was working correctly requires writing a file to a specific section of the disk, and then checking that section to see if the blocks are zeroed out. Since swap cannot be handled like a regular file system, this makes testing/confirmation impossible.

However, I did discover mention of a kernel feature on three different sites, one on Wikipedia:

Which was referenced from a page on the Fedora project:

I also saw mention of this one again under the Ubuntu FAQ:

I'm not 100% sure if this holds true when LVM/LUKS is involved, but assuming that TRIM has been enabled at those levels as well, I would guess that it does.

Based on this information, I'm going to assume that the kernel automatically handles TRIM commands on the swap partition without any manual configuration or optimization.

1 members found this post helpful.