Welcome to the MacNN Forums.

reRESERVEDMD · May 12, 2010, 07:53 AM

Hi,

Yesterday I got a new 128GB SSD drive. I've heard that they degrade over time especially if you defrag them etc. Now, I was wondering if verifying disk/fixing permissions etc. in Disk Utility works similar to the defrag? Should I do it or maybe just leave it as it is?

Thanks!

BTW: I highly suggest those =] Yesterday my computer started in 8 seconds and there's a noticeable increase in overall performance!

Simon · May 12, 2010, 07:59 AM

Don't worry about checking permissions on your SSD. Checking permissions is advice given all the time to solve almost any problem. People expect way too much from it and usually use ot way to often. But that aside, it won't have any negative effect on your SSD.

I also have a Core i7 MBP. I got a 160GB Intel X25-M 2G SSD for mine. I can only agree with you. There's an awesome speed-up from having an SSD as a boot/app drive in a notebook. My SL boot time went from 22s with a very fast 500GB 7200 rpm notebook HDD) to just 12s with the SSD. More importantly, application launches hardly ever take more than a bounce.

macaddict0001 · May 12, 2010, 07:13 PM

AFAIK all modern OS's defrag automatically. It may not speed up your SSD but it won't hurt it. They are designed for many read write cycles and an operation like a defrag tends to not write to the same area of the disk over and over anyway.

pwrmacg4 · May 31, 2010, 01:51 AM

Is heard some SSD are too fast for macs. Is this true? I have macbook core duo

reader50 · May 31, 2010, 02:36 AM

"Too fast"? In computer terms, there is no such thing.

If you heard that somewhere, it was probably a Windows user expressing sour grapes.

P · May 31, 2010, 03:22 AM

I must have missed this thread when it was up the first time...

SSDs require that cells be explicitly cleared before they can be overwritten, and this clearing is done by block. The clear operation is much slower than a regular write, so the SSD works very hard to avoid doing a clear when asked to write. Instead, it has some extra space so that all writing happens to a new, cleared block, and then keeps a translation table so that the OS always can find things where it expects them to be. If we call each block reported to the OS 1, 2, 3 etc, and each actual block A, B, C etc, then the table starts out by mapping 1=A, 2=B, 3=C etc, with some blocks X, Y, Z not reported to the OS at all. If the OS asks to overwrite block 1, or part of block 1, with something else, the SSD will write the new data to block X and change the mapping so that 1=X.

(There is also an issue in that these deletes can only be performed a certain number of times, so there is a longevity issue here, but that is a lesser concern these days as SSDs can take more deletes before a cell failing).

Any block that the OS considers free may at any point be overwritten with a new chunk of data - often, a very big chunk. If the block is really free to the SSD as well, then no problem - it will simply write where the data was intended to go. If the block was not free, it will write to a spare block and change the mapping. Here comes the issue: When the drive is new, all the blocks are free and both the SSD and the OS knows it. However, when the OS deletes a file, it doesn't inform the SSD about this - it just makes a write to some area of the drive (the file directory), or it clears the area physically (by overwriting it with zeros), but the SSD cannot know that the area is free and can be cleared. This means that the number of free blocks that the SSD can play with is reduced to only the spares - X, Y and Z in my example above - and this kills performance over time.

The solution is something called TRIM. TRIM is very simple - when the OS deletes a file, it reports the blocks that that file took up as free, and the SSD can use them as spares again. There is only one problem with TRIM: It must be added to the OS explicitly, and Apple hasn't done so with Mac OS X - yet. Windows has had it for some time, and persistent rumors has it that the feature will be added to Mac OS X in a point upgrade. It hasn't so far.

About defrag: Defragging means that files are copied and deleted all across the drive, triggering a lot of these delete-write cycles and remapping. One big defragging of a drive will reduce performance quite a bit, as suddenly that mapping table is completely messed up and the number of free blocks (to the SSD) is reduced to the reserved spare. That isn't what OS X does, however - it only rearranges some of the most used files into an agreeable pattern. I doubt that it makes any real difference to an SSD one way or the other, because the number of files moved is so small.

Big Mac · May 31, 2010, 04:04 AM

No TRIM huh, that's really surprising to me. So P, tell me if I'm understanding you correctly. Using an SSD on a Mac means that the SSD never technically gains free space when the Trash is emptied? How can that possibly be true?

reader50 · 05:22 AM

When files are deleted, the OS will mark the space as free. But the SSD works at the block level, it does not understand the file system. This is actually a good thing, it keeps SSDs file-system independent. If SSDs understood file systems, you can be certain they would only understand common M$ file systems. Unless you bought very expensive Mac-specific SSDs with Apple ROMs.

An SSD will preserve the contents of any block previously used until it receives a TRIM command telling it a block is free. Once every block has been written to once, the SSD will protect the contents of every single block. This gives less than ideal wear leveling and will drag down write performance. Especially on large file writes.

Why does it matter that SSDs preserve blocks you aren't writing to at the moment? Because SSDs cannot wipe single blocks. It is uneconomical to design an SSD that can do so. The file system uses 4 KB logical blocks, and 512 byte physical blocks ... but the smallest size an SSD can delete could be 4 MB. Or 32 MB. Let's say 1 MB (1024 KB) to make the math simpler.

Say you want to overwrite an existing 4 KB logical block - you've updated a small file. Since that block is already used on disk, the SSD has to erase the 1 MB range your block falls in before it can write new data to your block. It doesn't do a direct wipe - too slow. Instead, the SSD allocates a 1 MB hot spare, writes your 4 KB file to the proper place, then copies all the other 1,020 KB over to the new 1 MB addressable block. Finally, the SSD wipes the old 1 MB block to make a new hot spare.

So it may copy a lot of file system blocks that are free, because the SSD does not know they've been marked as free. This slows everything down and contributes to extra write cycles - which shorten the SSD's life expectancy.

Big Mac · May 31, 2010, 05:44 AM

Ah okay, so without TRIM command support the SSD is less efficient in managing space. I think I understand it now, but this is a complicated issue. . .

P · May 31, 2010, 05:54 AM

It is. Personally I'm hoping that the next Macbook Air will have a new SSD with TRIM support and launch with an OS X update that adds that support as well - that would be typical of Apple's way of handling things. Another possibility is a new MP with two drives, SSD and HD, or one of those hybrid drives that Seagate is hawking.

CharlesS · May 31, 2010, 11:56 AM

Originally Posted by reader50

"Too fast"? In computer terms, there is no such thing.

If you heard that somewhere, it was probably a Windows user expressing sour grapes.

What he's probably referring to is the Crucial RealSSD C300, which is actually faster than the 3.0 Mbps SATA controller in current Macs (and most PCs, still) is able to handle, and requires a 6.0 Mbps SATA controller for full performance. However, that doesn't mean it won't work — it just means that you won't get the full speed of which the SSD is capable, although it also means you'll probably get the maximum performance that's possible with your Mac.

macaddict0001 · Jun 2, 2010, 01:29 AM

CharlesS, you mean gbps right? That would mean a sustained transfer right above 350 Megabytes per second. I didn't know any SSD's were that fast yet.

P · 04:30 AM

Yes, he means 6 Gbps. That number is a raw figure, however, which includes a bunch of parity data. In effect, it takes roughly 10 "raw" bits to transfer one "real" byte, so 3 Gbps means roughly 300 (mini-)MB/s. The C300 has a reported sustained read speed of 355 MB/s.