"Defragmenting" a SSD based RAID setup

[aviat72]

Anand has an interesting article here about using SSDs in RAID-0 without TRIM support.
http://www.anandtech.com/show/3618/intel-x25v-in-raid0-faster-than-x25m-g2-for-250

He talks about potential performance degradation and ways to avoid it (smaller partitions, sequential writes etc.).

I was wondering if you could come up with a data-backup-restore scheme which puts the drives back in shape. Once the data is on disk how it got there (large sequential writes) or a lot of random writes should not matter. You could in principle "defragment" the SSD Raid by writing back the data in sequential manner.

Would would be the simplest way of creating a job like this?
When would you trigger a job like this (only after there is certain performance degradation)?

I just bought two V25-40G drives and will be putting them in a software RAID. I did not want to spend more bucks on drives which are nearing the end of their generation especially with the SATA-III interfaces coming on. These two will eventually go and become boot drives in older PCs.

 

[Nothinman]

That's how admins used to defrag unix, NetWare, etc servers way back when. Do a full back, wipe the drive and then restore. But that was also back when defragging had an actual, appreciable impact on performance as well...

 

[taltamir]

This will be as harmful to an SSD as regular defragging would be, and would not provide any benefits.

you should start by reading this: http://en.wikipedia.org/wiki/TRIM_(SSD_command)

The thing to understand, is that wear leveling means that the drives shuffle data internally, there is absolutely no relationship between the address given to the OS/FS for a particular data, and its actual physical location. Bottom line is, don't do it.

 

[aviat72]

This will be as harmful to an SSD as regular defragging would be, and would not provide any benefits.

you should start by reading this: http://en.wikipedia.org/wiki/TRIM_(SSD_command)

The thing to understand, is that wear leveling means that the drives shuffle data internally, there is absolutely no relationship between the address given to the OS/FS for a particular data, and its actual physical location. Bottom line is, don't do it.

The whole point is that in a RAID you do not get the TRIM commands. So you are likely to collect junk which is scattered in different places on the disk and will not get TRIMed out. This junk will result in write amplification and higher wear and tear.

As the wikipedia link also suggests, that there are tools like Intel's HDD-ERASE available to rest drives to a fresh state, which also delete all the data on the drive; Anand refers to it in his article as referred by the wiki.

What I am looking for is something which does something like HDD-ERASE to make the drives fresh and new AND then restore the data stored on the drive in a file-system aware manner.

So it will:
1. Backup:
(a) Create a File-System aware copy of the data stored on the SSDs; this will ensure that the untrimmed files are truly deleted.
(b) Also backup the boot partition and the OS files correctly.

2. Do an HDD-Erase to get the disk back to pristine state

3. Restore the data from Step #1,
(a) Recreating the Boot Partition and copying the OS files correctly
(b) Restoring the data collected in the file-system aware manner in 1(a)


This will obviously cost a few of the write-erase cycle so should be done sparingly, may be once every quarter or unless you start seeing performance degradation or the disk starts showing a significantly larger area used than what the file-system would suggest (I hope there is away of doing that; I am just ordered my first SSD today).

HDD-ERASE however requires changes at the BIOS level and other changes, which require manual intervention. I do not have much idea about how these backup systems operate (never used Acronis etc.) so do not know how feasible it will be to implement such a setup.

 

[taltamir]

ok, in that case it will just be grossly impractical. It will take HOURS to do and provide very little benefit. If your SSD without trim is 120GB + 8GB spare area, then after writing the first 128GB to it it will no longer be in "new" state.

The thing to understand is the "degredation" is a really bad term for it. Performance does not degrade over time, it drops, sharply, and stabilizes around a new figure (it still varies up and down a bit in equal amounts).

Anyways, since its so impractical, not useful, and requires such a wide range of disparate programs I expect nobody will make a program to automate it, and you really don't even need one... if you insist on doing it than:
1. Use a clone program to clone the partition to a spare HDD. (takes hours)
2. Break the raid array. (takes seconds)
3. Secure erase the SSDs (takes seconds)
4. Create a new array, don't zero it (takes seconds)
5. Clone the partition back to the SSD. (takes hours)

 

[Yellowbeard]

1. Use a clone program to clone the partition to a spare HDD. (takes hours)
2. Break the raid array. (takes seconds)
3. Secure erase the SSDs (takes seconds)
4. Create a new array, don't zero it (takes seconds)
5. Clone the partition back to the SSD. (takes hours)

1 and 5 aren't too bad if you have the luxury of cloning to another RAID array and if your first RAID stripe is not too big. The OPs SSD stripe is only 80GB. Ghost and Acronis are good. And, there is a tool called Clonezilla in Parted Magic. If it is a good tool and does what the name implies, Parted Magic is a single tool that will do all of the listed tasks.