Z Series SSD question and RAID/TRIM concerns

I'm reasonably sure I've artificially induced some degradation on the drives I've been pounding on. Writes have taken a decent nosedive. What's better is that I think I can repeat the steps I took to cause it.

I'm trying to think of ways to determine if GC is being done on the drives, either individually or in a RAID Volume.

Would sitting on my buttocks and letting it stew for a day or three be a reasonable course of action? I would take speed tests every so often.

It wouldn't tell us how, but if performance improves over time, it would indicate that some type of optimization is occurring.

Thoughts?

 

What sort of write speeds are you getting now that you have noticed a slow down ?

 

The effects of GC should be noticeable on a timescale much shorter than days. I would say leaving it idle for 2 hours should be enough to notice a very dramatic improvement.

 

No pressure buddy. You have done a lot already! Take your time

 

A few questions about SSDs, because this is too technical for me, and i'm confused...

1) Could someone please explain what % degradation would be expected, and at what intervals, for the Z' SSDs (worst case scenario, no software/hardware interventions, default system configuration) ? Eg, would the SSDs loose 50% of their speed in 6 months ? Or are we talking about 1% of the original performance per month (always talking about the worst case scenario, having the SSDs almost full)

2) The degradation is permanent ? Or either by a) formatting the drive or b) using software like Intel's SSD Toolbox, will the performance be back to 100% again ? (is it some kind of "defrag" actually ???)

3) I read in another post that Intel drivers are expected to fix the problem. Is that so, any estimates when they'll be released ?

Thnx

 

The Degradation depends on how much you use your Hard drive and if you regularly fill it up.

The degradation "should" be able to be fixed by 1. Breaking the RAID 2.Using HDDErase to secure erase the hard drive 3. Re-Creating the RAID .. This hasn't been confirmed yet, zoinksS2k will be testing this method soon. Follow this thread.

No estimates as to when Intel will release a RAID driver that supports TRIM.

 

Against my better judgement, here are two before/after shots.

Before the world catches on fire and this becomes a sniping contest on Sony,

I'm not done with my tests. I have not been able to duplicate the results because I'm not that far yet.. This could all be bogus.


If you want to know the level of detail I'm getting into, here's one of the test protocols I'm using.

These were when I got started. I opted to not reset the drives before starting, so this is with the drives and a few ghosts run on them.

All these are RAID 0, btw. I'm finishing the JBOD tests now.




This is after "seasoning" the drives


This was another triple-CrystalMark pass run a few minutes after the the triple passes above. Same boot session, I just went to answer the phone and forgot if I ran it or not. This is why I don't like this tool too much.

 

BTW, the two outputs to look at are ATTO and the "File Benchmark" passes of HD Tune. Performance is mostly degraded in the writes you see in them.

 

The Write speeds have halved according to ATTO.
HD Tune Pro does not show a big performance degradation.

How big a difference did you notice in real usage?

 

Can't do real usage when I'm busy punching the SSD in the junk, trying to make it slow

I will say its been exceedingly difficult to do this.

 

^ haha .. well that's good news for us .. somewhat ..

 

In other news, I have not been able to run HDDErase on the internal Sony SSD drives. I tried multiple versions of the app all the way back to 2.7 and from every boot medium possible.

It is looking as if the BIOS setting of RAID will keep this from working in the near term.

 

oh crap. Is there any other way to erase the SSD's to restore performance?

 

Now this is very important news. It means that those who said that this is no problem, because you can always wipe the drives if they hit saturation mode were wrong.

Yes, you need IDE mode to get HDDerase to work.

One workaround MIGHT be to use hdparm from linux to do a complete trim directly:

hdparm --dco-identify /dev/sdXXX
(to see the number of sectors on the drive, then: )
hdparm --trim-sector-ranges 0:$sectorcount /dev/sdXXX
(While the command will likely return immediately, wait a couple of hours while the drive erases the sectors one by one in the background.)

or, but this probably won't work without IDE mode either:

hdparm --security-erase /dev/sdXXX

or, but this depends on what the drive does when told to revert to factory reset:

hdparm --dco-restore /dev/sdXXX

If you're willing to boot from a Linux liveDVD and experiment with the above, it would be useful information. Needless to say, the commands are all destructive as far as data on the drive is concerned...

The question that now remains is whether TRIM works when using the drives in JBOD mode if using Microsoft's AHCI driver. My initial guess would be "yes".

 

^ yup .. now I am worried .. we have to find a way to wipe the SSD to restore performance .. or at the least enable TRIM in JBOD mode ..

 

I'm slightly confused by all of this when trying to apply it to linux. My system would only run ubuntu... Is everything that's being stated in these posts in-applicable to linux? Is raid on these drives with his controller, as well TRIM, supported already under linux?

 

Arth1,

I decided to forego my lack of Linux skills and booted to an Ubuntu 9.10 alternate.

hdparm showed that the drive is frozen. I don't have the screen output, but it sounds like what this Wiki article describes.

(text borrowed from wiki)

Code:

Security:
       Master password revision code = 65534
               supported
       not     enabled
       not     locked
       [B]not     frozen  <--ZoinksS2k's is frozen[/B]
       not     expired: security count
               supported: enhanced erase
       2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.

I've seen this before and got around it by reconnecting the SATA connector to the moboard shortly after or during post. I'm just not real hot on doing this.

Yet another reason for me to get the SDD out of the laptop and onto a test bench. This isn't real likely either.

While I have it, I'm going to try luck with some manual garbage collection with the wiper.sh script released with the recent hdparm.

 

In other, other news. The EFI hack to "feature enable" the BIOS doesn't work.

Because somebody will ask: http://feature-enable.blogspot.com/2009/07/enable-vt-on-insydeh2o-based-sony-vaio.html

I didn't expect it to, but had to try. As I've explained elsewhere, this hack was also killed off in newer BIOS revisions for my old Z591.

 

oh boy .. this is bad news for us Z users ..

 

This may be ignorant question, but is HDDerase the required utility or can another, such as dban or killdisk be used? And if so, then will those see the samsung disks standalone?

 

different type of erase.

 

Just to clarify, if you broke the array & went to JBOD could you then enable IDE-mode and permit HDDErase to work?

if so you can 'fix' the degradation at the expense of a full backup/image-restore process, right?

 

If you could change the BIOS to select IDE, yes. This was my experience on my old Z and OCZ/Intel SSD's.

Then again, if you could change the disk type from RAID to IDE in the BIOS, you might as well choose AHCI, because then trim would work (likely).

 

Well... Cutting edge technology and proprietary components with mix of control freak tendency Sony has, don't work well together.

 

Though it does not mean much unless someone will try it, version 5.1 of Killdisk on the website does say its SSD compatable.

I messed up my SSD (OCZ) a few weeks ago using version 5.0 of killdisk since I do not have an Intel (IDE) mobo and no way to get Sanitary Erase, nor HDDerase either. Had to send back the SSD to get it back to day one, and no longer will I buy another SSD until some nice, smart computer Geek comes up with a Sanitary Erase program for all mobo's, and either 32 or 64 bit operating systems. Too many hoops one has to go through to get these SSD's clean again.

Goodness sakes, can't the SSD manufacture do some thing good for once and help out the customers at time of sale and not have us rely on third party application that either do not work correctly on some systems or are too darn difficult to mess with unless you are a computer fanatic that loves to tinker with hardware/software all day long

 

Yes, relatively new versions of Linux will support Intel Matrix Raid striped disks, either with mdadm or dmraid.
No, TRIM won't work with striped disks, but it might work with JBOD -- either under Linux or Windows or both, depending on whether the commands are passed along or not.

 

If utilities like HDDErase won't work, what about manually writing 1's to the entire drive? It is my understanding that this is equivalent to resetting all the MLC flash cells.

Also, doesn't it seem like the HD Tune file benchmark, rather than showing any degradation, actually shows a slight improvement in write speeds for small file sizes after seasoning? Could you explain what the different sizes in the file benchmark mean? The fact that there's only one file size on the right that says 64MB is confusing.

 

And what about this?

Will you try if that works to restore performance on the drives?

 

Hi, Chirality!

I must apologize for injecting conjecture again, but I seriously doubt that this will help. The problem here is that the drive itself knows nothing at all about the file structure - it relies on TRIM commands to tell it what it can actually erase ahead of time so that relevant blocks may later become writable without an immediate (very slow, if in the execution path) erase to that block. If drives were to need to examine every single data byte that flows through them, it would have a quite serious performance degradation. I therefore very much doubt that any drive (today, at least) is capable of this.

With regard to the variation in benchmarks such as HD Tune, I wouldn't rely overly on this. The issue of write-combining is quite complex in the sense that speed variations are highly dependent on the present state of the drive. As ZoinksS2K's quite correctly concluded, it will take benchmarking over a large portion of the drive to have a more stable/realistic figure.

Regards!
Mark

P.S. - ZoinksS2K: I'm sorry that I'm not able to give you useful help on standard parameters for IOMeter - I've only played around with this on occasion, and don't know what magazines and websites use for their standard parameters (though I have seen a couple of references to 4K supposedly being the standard, I don't know more). My apologies!

Cheers!
Mark

 

One slight off-topic question & I apologize for that.

So does it mean that for the old VAIO Z series, we can use HDDErase on a SSD if we use a "hacked" BIOS & select IDE mode? It seems like it worked for you but I read something else as follows:

So which answer is correct? Sorry about all my questions. I'm asking because I'm considering getting a SSD for my old VAIO Z notebook.

 

why dont u just get the new Z and call it a day?

 

I'm not sure what you are referring to here, could you quote or link to the post that you are responding to?

 

SPEEDwithJJ, yes. I've done it many times.

As for the other questions. It really comes down to what "secure" means.

There are two perspectives:

1. The erasure of data. This is what the Sony cleaner, KillDisk, CCleaner and DoD-grade data eradication programs do. This is mainly useful for magnetic drives for "secure deletion." It is secure in that the data can't be read again. For SSD's without TRIM, this is just more writes. In fact, the I first heard of KillDisk was from a post at the OCZ forums where it made a guy's SSD slow down. I purchased it today for this very reason
2. Programs like HDDErase perform a "SECURE ERASE" command. For magnetic drives, it resets the LBA, or the drive's map of where data blocks are located on a disk. Added with multiple overwrites on all blocks, the drive's data is truely erased. For SSD's, this LBA reset effectively sets all the blocks to "erased" status, returing the drive to a factory-like condition.

A quote from Intel:

 

Howdy MJFlash,

Firstly, don't apologize. I haven't posted the data I've been collecting for you guys to review either. Guess I'm worried about the post getting out of control before I finish completely, which is a seemingly ever-distant goal. All I need is another test to run!

 

Hi, Chirality!

My apologies for not including the quote - I was referring to your most-recent post in this thread, as quoted above. My answer's still the same, which is:

Cheers!
Mark

 

Hi, Folks!

Chirality: If it helps, remember that the typical erase block is 256KB (i.e. essentially equivalent to a 1MB set of blocks with a x4 RAID0 array). Since the O.S. does random writes, there's little chance that the drive's cache would have much of a hit rate when trying to accept a write to a random sector. Instead, it would often have to read the entire 256K/1MB back first, then scan it to see if it contains all 0FFH, then could in your concept write the sector back to the drive. In reality, a very slow (~2 mS) erase will be necessary with anything I can presently imagine.

ZoinksS2K: Well, I do hope that I'll be able to help in the future! I would point out that if you ever get around to disassembling your unit, that that the "unplugging the SSD" step I noted doesn't require any compatibility. After booting DOS, you'd just plug it back into the Z and then run HDDERASE. If I do get my chance to take a trip to HK, I'll do this myself! Thanks again for all the great info!

Have Fun!
Mark

 

Hi folks,

I bought a new Z117 in HK as well, although I forgot to make recovery disks before I used Paragon Partition Manager v10 to split the C drive, and that unfortunated broke the bootmgr or something else which caused the recovery function totally unusable. Now I only have to wait for 7 days before SONY could make a copy of recovery disks for me (of course with $$$). :cry:

Back to the topic, I just read all the threads in the post. But still I'm a little confused for the following questions: Anyone could answer for me?

1. Is the experiment done by ZoinksS2k indicating TRIM is not working on New Z under the original Windows 7 x64, or it's indicating something else? I mean, what is the conclution of that experiment?

2. Is it confirmed that TRIM could not reach the SSDs in Raid 0 for New Z due to the limitation of Intel Raid driver although it is a software Raid?

2. As ZoinksS2k mentioned before, will this erase/wipe option help restore performance of the SSDs in New Z just like HDDerase could theoretically do?

Thanks!

 

Hopefully they are not charging you too much just for a recovery disk. Otherwise maybe someone you know could burn you off a quick one (maybe even someone on this forum would volunteer?) I won't have my Z for a few more days but if you haven't got something going by then, definitely pm me and I can burn an extra one.

 

Zoinks can you try the method below to restore your drive's performance.

http://www.ocztechnologyforum.com/f...TURBO-owners-with-FW-1-5-you-do-not-need-this

 

This is known as Tony-Trim. And yes, I've tried it. There was some speed recovered.

 

But not enough to perform like new? .. Any other ideas on how to regain the lost speed?

 

Not sure yet

 

Ah OK, I wasn't sure if you were referring to that one. I think the idea behind writing 1s to all blocks is that when a block is filled with 1s, that block becomes writable without needing to be erased first, since each cell in the block would be in the FFFF state, the writable state for MLC NAND flash. I think the theory is that the drive keeps track of blocks in this state for garbage collection purposes, and so when it is told to write to such a block, it does an immediate write instead of the read-write-erase cycle. This is the idea behind Tony-TRIM so it seems to work for some drives.

EDIT: oh cool, Zoinks has tried it and it may have an effect. Interesting.

 

I think if we run the Tony-TRIM method described in the link above, we might be able to prevent degradation to a large extent .. Precaution in this case might be better than cure?

 

Trying something new to load the drive. This should be more repeatable.

If I think did what the SSD hates more than anything else, filled every bock with random data. That sounds fancy, but I'm just using DummyFile to fill the existing disk space.

Looks something like this:



Strangely or not, the file creation speed GREATLY diminished as the C: drive filled up. The orange lines (writes) were solid at 200MB or so, then just slowed to a crawl until the drive had 276MB of space and DummyFile error-ed out.

I immediately restarted the same command to verify what happens when it fills the drive so I can loop it on the second drive. Yes, I'm still in JBOD.

I'm not sure what significance this write drop off is. I had kind of expected it since you really shouldn't fill up an SSD that way, at least not to 95% of it's capacity.

 

Hmm .. why does it say you only have 1 drive in Windows when you are running in JBOD? .. Did you not setup the other drive?

Maybe now you should now try to free some space by deleting those files and letting the drive idle for a bit and run some benchmarks?

 

It is unformatted so I can do write tests on it. Doesn't show in explorer.

I'm running the DummyFile app on the secondary drive with a simple looping batch file. I'll leave the primary drive alone for a few hours while the second drive gets thrashed.

 

^ ok .. keep us posted .. no sleep for you!

 

*Nod*

For reasons unknown, the second drive didn't show the slowdown when it reached capacity. Perhaps Windows was angry I was filling the OS drive.

Looks like the loop works. I set DummyFile to write a file larger than the drive itself. It errors out and starts over with a new copy of the same file, recovering the space previously consumed. I'll let this cook for a while.

If anybody is interested in doing this, here's the info:

@Echo Off
:TOP
DummyCMD g:\test.txt 55020807680 1
Shift
Goto TOP

I called it Dumb.bat

 

ok just so that I understand .. when it errors out due to lack of space how does it recover the space?