Indilinx controllers have pretty lackluster write amplification, so especially with the smaller Vertex models (30GB and 60GB) it's not too hard to burn through the flash write cycles in a relatively short period of time.

IIRC Indilinx write amplification is ~10, in that area. Intel and Marvell controllers are closer to 1.1. SandForce is about 0.6. Any drive based on one of these controllers should have substantially better durability than an Indilinx drive. People with Intel drives will often have lifetimes measured in decades as opposed to years like Indilinx drives. SandForce and Crucial drives should have similar durability to Intel.

frostedflakes

It sounds like you understand your stuff.

1. All things equal will a 120G SSD with 30G of data on it have 2x or 3x the number of writes than a 60G SSD with 30G of data on it?

2. Does wear leveling mean that even untouched files are moved around?

3. If an SSD uses its extra space for wear leveling, why does it help to convert some of that space into extra wear leveling provisioning space?

Not sure about other manufacturers, but Intel says you have to explicitly assign the additional spare area. They've even published a white paper on doing this to the G2 drives. Remember that all manufacturers already reserve some space for that purpose, obviously balancing cost against performance.

I found it I think:
http://cache-www.intel.com/cd/00/00/45/ ... 459555.pdf

It seems to say that not only does this improve performance but it does increase endurance.... but basically reducing capacity in half only increases life span by 50%. So that must mean that increasing total unprovisioned memory must extend the life of a drive, but provisioned memory gives it even more writes.

Does that make sense to you?

1. Yes. (the exact number is up for debate but it's more than 2x)
2. Yes, it's called static wear leveling (otherwise you would end up with uneven wear on the drive and lower lifetime).
3. I'm just speculating here but I think it has to do with the scheduling of the cleanup; having a certain number of free blocks (some only temporarily) is not the same as being able to count on having them always free. Also, if TRIM command is not supported, once you write to a block it remains a used block even if you delete the data afterwards, so by limiting the usable size you make sure you never write to a certain number of blocks.

I was doing some maintenance the other day, and discovered almost 10G of cruft that had been autoinstalled on my SSD C: drive (my free space had shrunk in half since the last time I looked, not a good thing. TreeSize is your friend). AND, indexing had been magically enabled too... Yikes. Something else to add to the list of things to check once in a while.

Related story: When I first installed Diskeeper 2010 (which has some SSD-specific features) on my XP system, it went into a defrag frenzy, and wrote over 10 TB in a day and a half! My wear-out indicator went from 95 to 83! A clean install of Win7 worked fine though.