Purchased a used laptop and an SSD. Any gotchas?

Hey guys. In a moment of rage and frustration with my 4yo laptop that has a 3500rpm hard drive (yes, 3500 rpm), I bought a HP Elitebook 8530W and a crucial M4 SSD. Linux support looks good on the elitebook, but I'm wondering if there are any gotches in regards to the SSD, particularly in terms of TRIM. I know trim is a big deal, and I know it requires OS support, but does it also require some level of chipset support? According to the HP website, the chipset is a Mobile Intel® PM45 Express Chipset ICH9M-Enhanced. Any other potential imcompatibilities in regards to TRIM?

As for the software end of things, I'm intending to run Ubuntu 12.10/ext4 for now, so I'll have a fairly recent kernel/filesystem. I know that I should add the noatime attribute to fstab, and set the trim option using tune2fs. Are there any other settings that I should be aware of?

Nope, you're good. (Been using SSDs and both Windows and Linux for going on four years now IIRC, including Crucial M4s.)

One BIG BIG BIG thing, though, since you got an M4 - UPDATE THE FIRMWARE. Seriously. Cannot emphasize this enough.

100%, yes you read that right, 100% of the Crucial M4s I've deployed in the last couple of years have had to get their firmware upgraded because all but the very most recent had a "sleeper" bug that would cause the drive to start dropping off the SATA bus entirely. Once the bug starts showing, it gets worse and worse - at first it happens once in a blue moon, eventually it gets to the point where it'll happen in less than 5 minutes. Upgrading the firmware fixes it. (I haven't experienced any dataloss due to this bug, but hooboy have I ever had to work a lot of unbilled hours because of it.)

And yes, even if you just bought it, odds are good it has older firmware. A lot of vendors seem to buy these things in GIGANTIC loads that they then piecemeal out for months and months and months - and the vendor may tell you that it has the latest firmware, but in practice they don't know or don't care. Caveat emptor, check behind 'em, make damn sure for yourself.

M4 will do TRIM, so just mount ext4 or XFS (kernel >3.2 needed, IIRC) with "discard". As Jim says, do the firmware update. I think if it tips over 521 power-on-hours without firmware update, a SMART register overflows. Not completely fatal - it will still work for one hour with every cold boot, until it increments the register again and panics itself.

* break the living hell out of any mailservers you may happen to be running* not be able to keep user crontabs* potentially plenty of other Very Irritating Problems, as the system does not expect /var/spool to be volatile - applications (such as but not limited to mailservers) which keep spool directories DO NOT EXPECT TO HAVE TO RECREATE THEM WITH EVERY REBOOT, which they will have to do if /var/spool is volatile!

Interesting. While I wasn't going to be doing that to /var/spool (this is for my development laptop, no mailserver here), I *was* planning on doing that for /tmp, as the development I'm doing writes a LOT of logging to /tmp. Do you see any reason not to do it to /tmp or /var/tmp?

/tmp and any **/tmp directories are intended to be volatile by definition and thus should be fine as tmpfs filesystems. Any app that expects a **/tmp folder's contents to survive a reboot is implicitly broken.

* break the living hell out of any mailservers you may happen to be running* not be able to keep user crontabs* potentially plenty of other Very Irritating Problems, as the system does not expect /var/spool to be volatile - applications (such as but not limited to mailservers) which keep spool directories DO NOT EXPECT TO HAVE TO RECREATE THEM WITH EVERY REBOOT, which they will have to do if /var/spool is volatile!

Interesting theory. While I don't run a mailserver or cronjobs on my laptop. I see that this could lead to unexpected behavior. Thanks Jim. Removed it from my post and /etc/fstab.

"Yes, but it will still kick the ass off a conventional hard drive, so whatever" basically.

I still have Intel X25-M 80GB SSDs deployed that have been in heavy daily use for >3 years, and yeah, they're slower than they were, but they're still LEAPS AND BOUNDS better than conventional drives.

I don't know anything specifically about your Toshiba, but assuming it's a relatively decent performing drive to begin with, it should still be relatively decent even after a few years of degradation due to lack of TRIM.

noatime and nodiratime will decrease the writes to the drive somewhat, but probably not to the point of making all that significant a change to the lifespan of the drive. particularly since relatime has been part of default options for quite a few years now.

I'd say, if you care about atimes, leave 'em enabled. If you DON'T care about atimes, disable them. (I'd say the exact same thing about an FS on a conventional drive.)

From reading here I assume that I just need to add 'dsicard' to the fstab but what about in conjunction with LVM? Do I need to add 'discard' to every entry in the fstab for the LVM partitions? Also some Googling indicates that I should be enabling the 'issue_discards' option within lvm.conf. Suggestions?

From reading here I assume that I just need to add 'dsicard' to the fstab but what about in conjunction with LVM? Do I need to add 'discard' to every entry in the fstab for the LVM partitions? Also some Googling indicates that I should be enabling the 'issue_discards' option within lvm.conf. Suggestions?

Not completely certain about the LVM layer but yes, you should issue discard on every partition you want to use TRIM on. To see if the change in /etc/fstab propagates through the LVM partitions use the following command: lsblk -D

If you see "0B" displayed in the DISC-GRAN and DISC-MAX columns TRIM is not enabled.

I haven't added the 'discard' command to fstab as you can see below but the output of lsblk -D says something is happening. Could it be that the OS or drive itself is doing something TRIM related or am I reading too much into this?

So when I have a chance to reboot I'll rerun the test and see what happens. I don't want to reboot remotely incase adding the 'discard' command to the fstab blows something up, unlikely but just in case.