Is TRIM overrated?

Downloading it now, its a big program what from I can see. 10 min left on download. Can anyone else confirm that parted magic is a good tool to use?

Nope, you should not use it.

So what you saying you are not sure if partitioning each hdd separetly at 40gb is any better if doing it all at once 80gb after raid is setup...

Not even remotely what I wrote.

Are you sure the complexities of RAID are suited to your level of computer use?
 
Nope, you should not use it.

Not even remotely what I wrote.

Are you sure the complexities of RAID are suited to your level of computer use?

Why not?

You sad this your self dude what are you talking about?

If you secure erase the two SSDs, then create a RAID 0 out of them, and then create a partition on the RAID volume, starting at the beginning, that is 80GB less than the total available space, I think that will accomplish the same thing as partitioning each drive separately, 40GB less on each. However, I cannot be certain

Are you sure the complexity of English writing is suited for your lvl of understanding?

no need to get rude
 
I just spend about 2h on this! and no luck.... I had to take out 4GB of ram for the program to even start, when i FINALLY got to all the propper menues, my C300 wasnt even there... all the other 3hdd were but not the one i needed.

According to: http://www.iishacks.com/2009/06/30/how-to-secure-erase-reset-an-intel-solid-state-drive-ssd/

"You must also disable AHCI (SATA Mode) if enabled in your BIOS before you boot into DOS for the utility to run and work properly. Most BIOS will have an option to emulate IDE mode for SATA ports. Be sure to switch it back to AHCI once you are done."

I changed from AHCI to IDE I tried "Enhanced" version and "Compatible" version of it, I did not have the word emulate anywhere in the BIOS, anyways only one of them allowed me to even get access to the needed boot menu via cd-rom and even then it still had a sign telling me that the drive wasn't running in the emulate mode...

Hmmm. I used a bootable USB stick the times I tried it, and unhooked all the other drives in the system. I do recall hearing some people say that you need to have the drive plugged into the SATA 0 connector, but I don't think I had that issue - it was dead simple for me. I had to set IDE mode, as mentioned - I can't recall which setting I used - but after that it detected the drive just fine (Intel and OCZ drives).
 
Actually, leaving some space unpartitioned (aka unformatted, unused) is helpful for GC in the same way that TRIM is helpful for GC : having more unused pages to work with makes GC more efficient.

That's if the controller can know they're unused, which I won't believe until proven otherwise.
 
That's if the controller can know they're unused, which I won't believe until proven otherwise.

If the controller is TRIM capable, of course it knows. The pages are marked invalid after a secure erase, same as if they were TRIMmed.

If you require more proof than that, just look at some of Intel's presentations. They specifically refer to gains that can be had by leaving some portion of the available SSD space unused.
 
If the controller is TRIM capable, of course it knows. The pages are marked invalid after a secure erase, same as if they were TRIMmed.

In theory, even a non-TRIM controller (e.g. Intel Gen1) should know as long as the drive was secure erased, and never sees a write to any logical sector outside of the partiton boundaries. Whether those early drives were actually smart enough to exploit the extra space for GC is a different question.
 
In theory, even a non-TRIM controller (e.g. Intel Gen1) should know as long as the drive was secure erased, and never sees a write to any logical sector outside of the partiton boundaries. Whether those early drives were actually smart enough to exploit the extra space for GC is a different question.

Good point. I cannot remember whether any of Intel's presentations referred to using the extra-space technique with a G1 SSD (and I don't care enough to look it up now), but I guess that they did.
 
I cannot remember exactly where I saw it, but you could check the previous two years IDF conferences (not the most recent IDF, the previous two years).
 
I managed to find a floppy drive, and it seems to work much better with less problems the booting via cdrom. When i get to the stage where I need to select my drives for secure erase, both of my C300 are invisable, my other 3hdd are there tho. Im using HDDErase 4.0

Any suggestions on how to make the HDDerase see the SSD's?

On Crucial forums I was told that using Parted Magic is not a good idea, since it writes 0's and that's the worst possible thing, because empty for an ssd is all 1's, not zero.
 
Try unplugging all the other drives, and just have one SSD at a time hooked up. It may also help to plug it into port 0, and be sure to be in IDE mode in the BIOS (try both of them if there are two modes).
 
Thank you Forceman, plugging it to SATA 2 and unplugging everything else has done it!

Now i just need to find that windows 7 CD. Can windows 7 be installed from a flash drive? or is it not recommended?
 
On Crucial forums I was told that using Parted Magic is not a good idea, since it writes 0's and that's the worst possible thing, because empty for an ssd is all 1's, not zero.

Not if you use the erase disk / secure erase function.
 
if you look here http://linhost.info/2010/06/parted-magic-erase-a-hard-drive/

it specifically saying that it writes zero's to entire data area... maybe im missing something

Yes you are missing something. That article is referring to a magnetic platter hard drive. The "secure erase" tools you are looking at (especially dban, dd, etc.) are not doing the same kind of "secure erase" as is done at the SSD firmware level.

This is a huge oversimplification, but think of the bits on an SSD as a bag of party balloons. When you first buy the balloons, they are all squished up in the bag. You take them out and begin filling them. Some you fill with air (1's) and some you fill with helium (0's). If you line the balloons up in a row, you have a sequence of binary digits, and, thus can represent information. Now, say you want to remove the information from the balloons. You can refill all the ballons with helium (zero wipe) or with air, or you can just refill them randomly. You may have to do this several times to remove all traces of the gas you had in the balloon previously.

This is what happens when you wipe a magnetic drive. Every balloon always has to be filled with something, either air or helium.

But an SSD has a third state that the balloons can be in. Remember when you first got the balloons, they were all collapsed. This is the third state - empty, as in containing neither 1 nor 0, just unused, or erased (remember I said this was a huge oversimplification). Magnetic balloons don't have this state.

Now, here's the key point of the analogy. When I want to change the gas in an SSD balloon, I always have to empty it first. I have to let the old gas escape, which takes time. Magnetic balloons don't have this limitation. I can take a balloon filled with air, hook it up to the helium nozzle, and it will instantly exchange the air for helium or vice versa.

To make filling the SSD balloons faster, I can have a supply of empty balloons on hand. When I want to change the information contained in the balloons that are, say, in the living room, I can fill up a new set of balloons with the new information. Meanwhile, a helper can go into the living room and remove the old balloons and start emptying them, while I just put the new balloons in right away. This is garbage collection. The information in the living room looks like it changed instantly, but it's not really the same balloons. I shuffled the balloons around behind the scenes and kept track of which balloons went where, but the guests don't notice that. If you don't have a supply of empty balloons, you can't do this. You always have to empty some old balloons first before filling them.

What a "real" low-level firmware security erase does on an SSD is empty *all* the balloons. Those high-level erasers like DBAN are very effective at jumbling the information on the disk so that people can't steal your information, but they still leave all the balloons full at the end of the operation, thus you get no performance benefit.

Like I said, this is an oversimplification. The "balloons" in this analogy aren't really individual bits, they are large blocks of SSD memory (even larger than a magnetic disk sector). And they are never really "empty". They do still contain, I think, all 1's when in the erased state, it's just that the firmware *marks* them as being empty. When you run DBAN or the Parted Magic thing you linked to, the SSD firmware has no idea that you are trying to erase the disk. It just sees a bunch of data being written and doesn't care whether it's all 1's or 0's or a random wipe sequence. It's all just data. The only way to truly mark an SSD block as being erased is to either do a real security erase, or else issue TRIM commands to tell the firmware that, yes, I really do mean to empty these logical sectors.
 
Apparently what I'm searching for are videos from Intel at the IDF, but I can't find them. I've seen conflicting accounts of them, one saying that you needed unpartitioned free space, the other saying that partitioning didn't matter, you just had to not fill the drive (which is what I tend to believe). The garbage collection would have to be pretty smart, and use lots of space for its database, to account for several GB more of provisioning than what the firmware is calibrated for. Yes, wear leveling will be helped (but not more than by simply not filling up the drive), but GC, I'm still not convinced.
 
No, you are still missing the obvious. The GC does not have to have any extra smarts. Unused pages are marked as "invalid" in the controllers internal tables. It does not matter if it is marked invalid because of a secure-erase-never-used condition, because GC has freed it, or because of TRIM. GC works with invalid pages, the more the better.
 
What I'm doubting is the capacity of GC to mark invalid more pages than what it's designed for, basically doing trim on its own.
 
What I'm doubting is the capacity of GC to mark invalid more pages than what it's designed for, basically doing trim on its own.

I suspect the problem is that you are misunderstanding how GC works in most SSDs. There is no limit to the number of pages that can be marked "invalid". (By the way, I've never liked that term for unused pages, but that is what the firmware people seem to prefer). After the drive has been secure-erased, ALL of the pages are invalid. There is no limit. All GC does is go through pages of flash, collecting invalid pages together into at least erase-block-sized chunks. There is no special designated pool of flash that GC may use or not use. All of the flash memory is examined by GC.
 
There is a lot of confusion about TRIM and garbage collection (GC) in SSDs. In a nutshell, the most common type of GC is a kind of internal defragmentation where unused (aka invalid) pages of flash memory are collected into larger chunks (at least erase block size) by shuffling data around, and then the collected blocks are pre-erased, ready for writing. Since erasing a block takes a relatively long time, having a supply of pre-erased blocks will speed up future writes. There will always be some unused pages for GC to work with, since the SSD reports less sectors available than it actually has flash memory.

All TRIM does is mark unused (aka invalid) those pages of flash that the filesystem is no longer using, assuming the filesystem is TRIM-capable. Having certain pages of flash marked unused provides GC with more pages to work with, thus making things more efficient (less wear-and-tear on the flash, more pre-erased blocks). But the unused pages do still need to be GCed, and that does not necessarily happen at the instant the TRIM command is sent to the SSD (that behavior depends on the specific firmware of the SSD).

+1

He knows what he's talking about.

I personally would stick with TRIM and a single SSD, but if RAID 0 is necessary, like the others have said, leave 20-40GB of each SSD (not the array) unformatted to allow GC to work better.
 
I also find Parted Magic to be the easiest way to do a Secure Erase. Note that their disk erase tool is DBAN-like by default, made to overwrite magnetic remnants on a platter HDD. However, there is an option in the tool to instead use Secure Erase. For SSDs, overwrite == bad, Secure Erase == good.

For security, the BIOS may have a block on the Secure Erase function. Note that Secure Erase is implemented by the drive's controller, and these "Secure Erase programs" are simply sending a command to the drive to actually start a Secure Erase. Without any protection, it would be possible for a virus to tell your drive to wipe itself clean. I have an old Dell PC at work that I use for wiping disks (mobo has IDE and SATA, and I added a SCSI card), and I couldn't get Secure Erase to work at all until I downgraded the BIOS one version. You may have to hotplug the drive to be wiped after booting or change the BIOS settings/version.
 
I suspect the problem is that you are misunderstanding how GC works in most SSDs. There is no limit to the number of pages that can be marked "invalid". (By the way, I've never liked that term for unused pages, but that is what the firmware people seem to prefer). After the drive has been secure-erased, ALL of the pages are invalid. There is no limit. All GC does is go through pages of flash, collecting invalid pages together into at least erase-block-sized chunks. There is no special designated pool of flash that GC may use or not use. All of the flash memory is examined by GC.

I'll try again. Once you've used the SSD for a time, all the pages have been written to. Without trim, how does GC knows that XX GB are invalid ? It has to use a database.
 
I'll try again. Once you've used the SSD for a time, all the pages have been written to. Without trim, how does GC knows that XX GB are invalid ?

One part of this is SSDs retain extra capacity so you can not have every single page valid at once.
 
I'll try again. Once you've used the SSD for a time, all the pages have been written to. Without trim, how does GC knows that XX GB are invalid ? It has to use a database.

Is the confusion due to the meaning of invalid? That term does NOT mean that the page has never been written. It means that the page is not currently in use. In other words, it does not contain valid data.

All pages will have been written to eventually, but there are still many pages marked invalid in the index (what you call the database). In the absence of TRIM, after all of the ATA sectors (LBAs) that are in partitions have been written at least once, the number of invalid pages will be equal to the amount of reserved space in the SSD plus the amount that was left unused (unpartitioned) when the drive was last secure erased and partitioned. The specific pages which are marked invalid will change as data is written to the SSD and GC and wear-leveling are occurring, but GC and wear-leveling will create the same number of invalid pages as they take away, so there will be no net change in number of invalid pages due to GC and wear-leveling.

With TRIM, the number of invalid pages I mentioned previously will be a lower-limit (i.e., there will always be AT LEAST that many), since TRIM can increase the number of invalid pages.
 
Last edited:
Thanks to everyone who helped.

Here are some ss of before and after;

Before single C300 128GB SSD 0007 firmware
0007.png


After RAID-0 C300 128GB SSD
Raid-02.png


I updated firmware on both SSD's to the latest 0007 version before raiding them, since its not showing on the AS SSD are there any more firmware updates I need to do?
Whats a good website to tweak your SSD, perhaps increase possible performance?

Thanks
 
The big deal about Secure Erase is that it cleans/clears/zeros the drive's LBA.

AFAIK, It's not zeroing the drive that reclaims SSD's "out of the box" speeds but zeroing the LBA does.


This is also why partitioning a spare area makes sense when TRIM isn't avaliable.

Does it matter if the spare partition is formatted? I dunno but since a clean-unwritten partition will take a reinstall/repair/image install I always left them RAW.
 
Last edited:
I updated firmware on both SSD's to the latest 0007 version before raiding them, since its not showing on the AS SSD are there any more firmware updates I need to do?
Doesn't look bad.

Do you have write caching enabled? If not, do it and see if your 4K scores increase.

Are you using the latest Intel drivers?
 
Does it matter if the spare partition is formatted?

If it is formatted then it has at least some data (the empty filesystem structures) on it that will be marked on the SSD as valid so that will be slightly defeating the purpose of setting aside an area of unused blocks.
 
If it is formatted then it has at least some data (the empty filesystem structures) on it that will be marked on the SSD as valid so that will be slightly defeating the purpose of setting aside an area of unused blocks.
I dunno but since a clean-unwritten partition will take a reinstall/repair/image install I always left them RAW.
Kinda what I figured and it sounds good. :)

Maybe this will get everyone on the same page. :)
 
One thing I've always wondered about secure erase is whether it also resets all the wear-leveling information. If so, it's probably not a good idea to do it more than a few times.
 
Wow, I learned a lot about trim! Thanks guys! Very enlightening.

1) So, to see if I understood it correctly from your discussion: All deleted data blocks needs to GC to be reused. TRIM marks the deleted data blocks faster, so it allows faster GC? Kind of? Or did I misunderstand?

2) Another question. You say to leave 40GB empty on each drive in raid. The 40GB should be left out of the raid, it should be "RAW" unpartitioned space. It sounds as if I should do the same, leave out 40GB on my single SSD system disk?

3) Now I am using the entire disk as system disk, it has no 40GB space unpartitioned. What happens if I make sure that I never fill my drive than 80%? Always 20% space is free? Will this benefit the GC, so he has more pages to work with? In effect, if you have an raid, you dont have to leave 40GB unpartitioned but instead you can make sure to always stay below 80% utilization so the raid will always have empty space to use? Is this correct?
 
Back
Top