Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Source code editing and SSD wear?

Hi there!


I'm using a brand new late 2010 13'' Macbook Air for coding. I'm really amazed by this tiny (yet very capable) machine, and enjoying it a lot.


However, I see that TRIM is not yet enabled for this machine on the current 10.6.7 OSX. I'm a bit worried of SSD wear (yes, it's my first SSD machine 😁 ), mainly because when you edit code, you overwrite the files you're editing a lot of times per session. While the limit of 10000 writes may seem high for casual users, I feel it's a low number when editing code. I feel that TRIM could lower these worries, as I guess it would write data into blocks with the fewest writes, in order to have uniform write numbers across the SSD... (well, I'm just guessing, I never used SSDs before).


I was considering using a ramdisk for programming, in order to save the SSD lifetime, but maybe I'm exaggerating... I just don't know.


Is there some way I can force OSX to use a huge disk cache and only write it to disk at shutdown? (my Macbook Air has 4GB RAM, and I can afford using 1GB for disk cache, if it was possible to manually configure the cache behaviour).


Thank you in advance,


cesarpixel

Posted on Apr 25, 2011 1:47 PM

Reply
Question marked as Best reply

Posted on Apr 25, 2011 1:59 PM

I would worry more about filling it up before wearing it out. It will be time to replace it with something larger first, I think. Check your warranty - buy the extended (Apple Care) warranty if that sounds appealing for any reason.


As for writes, OS X purposely writes non-contiguous.


You can always connect an external drive and work projects there if you're worried.


As well, jump the ram too.

10 replies
Question marked as Best reply

Apr 25, 2011 1:59 PM in response to cesarpixel

I would worry more about filling it up before wearing it out. It will be time to replace it with something larger first, I think. Check your warranty - buy the extended (Apple Care) warranty if that sounds appealing for any reason.


As for writes, OS X purposely writes non-contiguous.


You can always connect an external drive and work projects there if you're worried.


As well, jump the ram too.

Apr 25, 2011 4:19 PM in response to K T

What's the real meaning of the "non-contiguous" writes of OSX? Does it mean that it always writes into cells higher than a "current write pointer" which is incremented in each write? I suppose this approach would help to have a uniform wear across the SSD. Otherwise, if it always searches for free cells starting at the beginning of the SSD, some cells will be used more than the ones located at the end of the SSD.


Is the behaviour of this subject of OSX explained somewhere?

Apr 25, 2011 5:22 PM in response to cesarpixel

It's the same reason fragmentation went away as a major issue when OS 9 was left behind.


adaptive hot file clustering


Most files on a disk are rarely, if ever, accessed. Most frequently accessed (hot) files are small. To improve performance of these small, frequently access files, they are moved near the volume's metadata, into the metadata zone. This reduces seek times for most accesses. As files are moved into the metadata zone, they are also defragmented (allocated in a single extent), which further improves performance. This process is known as adaptive hot file clustering.

The relative importance of a frequently used (hot) file is called its temperature. Files with the hottest (largest) temperatures are the ones actually moved into the metadata zone. In Mac OS X version 10.3, a file's temperature is computed as the number of bytes read from the file during the recording period divided by the file's size in bytes. This is a measure of how often the file is read.

Apr 26, 2011 2:08 AM in response to K T

Remember that my question isn't about SSD wear in general, but relative to the use of a SSD for programming. I'm not sure if "adaptive hot file clustering" helps to uniform SSD wear, or if it makes it worse.


Let's suppose you're editing MyClass.cpp. Let's suppose it's a 20KB file. You're actively coding in that file, and you save it every 5 minutes or so.


What happens everytime you re-save that file? Is it overwritten in the same cells in the SSD? If affirmative, then it's a problem, because you could reach the 10000 writes limit in weeks for some cells, while other cells in the SSD would still be with zero writes.


On the other hand, if everytime you re-save MyClass.cpp it's written in a new location, then that's fine, and that would help to have a uniform wear across the SSD. By a "new location" I mean that some pointer (either in OSX or in the SSD controller) should keep track of the address of the last write. Whenever it writes again, it wouldn't look for free cells from the beginning of the disk, but after that "last write address", and then that pointer would increment. If that's the behaviour, then it's fine, and a 200GB SSD would last for more than 3 years even if you're saving your file every minute. Otherwise, if it's overwritten in the same cells, you can begin trashing cells in you SSD in a matter of weeks.


That's what my question is about. In short, I guess it's "how are files overwritten in a SSD? on a completely new location or over the same cells?"


Thanks a lot again for all my comments!!

Apr 26, 2011 5:08 AM in response to cesarpixel

It is my understanding that every write takes place in unallocated space and, if successful, the previous blocks are deallocated. I'm not a hardware guy so I can't point to the paragraph in the spec where it says that in so many words. Still, the filesystem makes no further effort to disperse data throughout the drive. You are still likely to write in the same general area of the disk. OWC sells aftermarket SSDs that have logic that is supposed to disperse data across the entire drive.


If you buy a MacBook Air, that is just the price you pay.

Apr 26, 2011 6:31 AM in response to etresoft

According to this good article, the SSD firmware tries to use all cells in a uniform way, although it's not as efficient as it could when TRIM is not enabled (and it's not enabled on the Macbook Air as of 10.6.7... I hope they enable it soon).


The page:

http://www.tuaw.com/2011/03/27/keeping-ssds-in-trim-doing-the-math/


And the quote of interest (from that article):


That way, even if the user's operating system keeps writing to the same single file over and over again (perhaps a page file or your Safari history store), then those writes are recorded onto different cells. This process works best when the firmware has as much free space to choose from as possible when incoming write requests are received so that it can choose the least worn cells to handle the data. Without TRIM, the firmware thinks a lot more of the drive is in use than really is, so it has less scope to spread the wear around. Thus, not having TRIM support can lead to parts of the disk wearing out prematurely


Anyway, I find it a bit annoying not to have any official Apple technote about this, because it would really help to know the expected longevity of your drive. And I really hope they add support for TRIM on the Macbook Air as soon as possible!!

Apr 26, 2011 6:42 AM in response to cesarpixel

cesarpixel wrote:


What happens everytime you re-save that file? Is it overwritten in the same cells in the SSD? If affirmative, then it's a problem, because you could reach the 10000 writes limit in weeks for some cells, while other cells in the SSD would still be with zero writes.


Entire files aren't rewritten each time you save. The change is written to a new location. When the original write expires it is freed up - simply marked as available, not zero'd out...the data is still there.


If the original file represents 10 characters in a string (+ name, date and location on disk), and you change 2 of them, the data representing the original 2 on disk is marked as free and the data representing the new 2 is written somewhere else. 1 write of one size (10 chars + created date to the index) and 1 write of another (2 chars + modified date).


The Air is the last computer Apple sells I would recommend for dev work (which tends to consume, rather than demand, resources), but not for the reason you're proposing.


The article you quote doesn't seem to change anything....write cycles are limited, sure.


Again, it has a warranty...if Apple Care is still an option, buy it if you're worried. You own it now...seems like the horse has left the cubicle 😉

Apr 26, 2011 8:35 AM in response to K T

K T wrote:


The Air is the last computer Apple sells I would recommend for dev work (which tends to consume, rather than demand, resources), but not for the reason you're proposing.


Well, I needed the same performance of my previous C2D laptop, but fitted in a lightweight design, because moving a heavy case all the day was starting to cause harm to my back.


The stressful CPU and GPU tests that I've done to the Air show that I was right (performance is the same -sometimes higher- than my previous laptop) and these tests also show that the people who believe the Air is just for email and Office are wrong (I've solved several huge sparse matrices which take the whole 4GB of RAM to invert the matrix, and I can say that it has the same performance as my previous laptop). I've to say however that this Air model is the top max one: 13'' screen, 2.13GHz, 4GB, 256GB.


It's a matter of time that people will abandon the belief that Airs can't be the main work machine. Either future Macbook Pros will become as light as the Air, or either the Air will get similar performance to the Pros, call it how you like, but the fact is that users need the performance of the MBP on the MBA, and Apple knows that.


But, yes, the mindset of a big part of the Mac community who think the Air is a toy has to change.


K T wrote:


The article you quote doesn't seem to change anything....write cycles are limited, sure.


Yes, it's quite a big change: If the firmware always writes into cells with the minimum write count, it changes everything.


In fact, now I'm reading that the Toshiba SSDs that ship in late 2010 Airs might perhaps have a very clever firmware, maybe as clever as even being able to understand the HFS filesystem:


http://www.macworld.com/article/156227/2010/12/macbookair_torturetests.html


I'll install Lion as soon as it's released, just because of TRIM. But in the meantime, I believe the SSD firmware in the Air is quite clever, at least from what I've read.


Thanks a lot,


cesarpixel

Apr 26, 2011 8:43 AM in response to cesarpixel

>But, yes, the mindset of a big part of the Mac community who think the Air is a toy has to change.


It's just a tool, albeit niche, like anything else - different strokes for different folks. I don't really expect it to survive given the rise of the iPad, tho.


As I said, dev work consumes resources. I don't think it represents anything unique beyond any other type of usage. Discussion here in the past recommend anything but the air for dev work BTW.


For my money, a refurb'd mac mini server from the Apple Store, coupled with external FW drives and large monitors, is still the best investment, bargain wise.

Source code editing and SSD wear?

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.