Mtron SSD Failure

Silencing hard drives, optical drives and other storage devices

Moderators: NeilBlanchard, Ralf Hutter, sthayashi, Lawrence Lee

Post Reply
victorhortalives
*Lifetime Patron*
Posts: 207
Joined: Wed Aug 08, 2007 1:50 am
Location: Xhystos

Mtron SSD Failure

Post by victorhortalives » Wed Oct 01, 2008 10:19 am

This is just to inform fellow forum members about a recent failure with one of the Mtron SSD SLC 16GB drives.

This is a 2.5in drive and is about 6 months old. Was running Xp ProSP3.

It suddenly wasn't there anymore !

It suddenly became unrecognised by WinXp. I reinitialised the drive (didn't format it), moved it to another PC for test. It died again. Reinitialised it, did a quick format, it is not able to be tested by either HDTune or HD Tach. No previous partitions can be found by Stellar Phoenix or Nucleus recovery software programmes.

It now reports a 16MB capacity !

Sounds to me like a controller failure. To their credit Mtron responded very quickly and will RMA the drive. My problem is that there is a lot of sensitive data on the drive. Will they be able to access it or not ?

With a conventional drive a strong magnetic field will erase most of a defective drive. Shall I RMA the drive or accept the failure ?

Now I have reinstalled my 74GB Raptor as my other drive (system drive remains as another Mtron). So my very very quiet very very fast PC is no longer so quiet or so fast !

AuraAllan
*Lifetime Patron*
Posts: 713
Joined: Wed Mar 07, 2007 7:49 am
Location: Denmark

Post by AuraAllan » Wed Oct 01, 2008 10:42 am

Hello

Sorry to hear about your trouble.

How about sending it in for repair?
Changing the controller should do it, I guess.

Makes me a bit worried as I have a 32GB Mtron SLC in my laptop. :?

Vicotnik
*Lifetime Patron*
Posts: 1831
Joined: Thu Feb 13, 2003 6:53 am
Location: Sweden

Re: Mtron SSD Failure

Post by Vicotnik » Wed Oct 01, 2008 1:59 pm

victorhortalives wrote:My problem is that there is a lot of sensitive data on the drive. Will they be able to access it or not ?
Damn, I hadn't thought about that.. I have a Mtron 16GB too, and some sensitive data on it. Maybe I should move the stuff to one of my regular HDDs.

AZBrandon
Friend of SPCR
Posts: 867
Joined: Sun Mar 21, 2004 5:47 pm
Location: Phoenix, AZ

Post by AZBrandon » Wed Oct 01, 2008 4:37 pm

In the future... http://www.acronis.com/

Vicotnik
*Lifetime Patron*
Posts: 1831
Joined: Thu Feb 13, 2003 6:53 am
Location: Sweden

Post by Vicotnik » Wed Oct 01, 2008 4:51 pm

AZBrandon wrote:In the future... http://www.acronis.com/
Oh, I have backups. It's just that with a failing HDD I usually wipe the disk before sending it in. I hadn't thought about that one might not be able to do that with a failing SSD.

Best to never keep sensitive data unencrypted on any drive I suppose. TrueCrypt ftw. :)

victorhortalives
*Lifetime Patron*
Posts: 207
Joined: Wed Aug 08, 2007 1:50 am
Location: Xhystos

Post by victorhortalives » Thu Oct 02, 2008 1:48 am

RE : In the future... http://www.acronis.com/

I have Acronis 11 and tried to use the DriveCleanser tool. Didn't work.
Backups I already do so not much data lost.

No answer yet from Mtron about what they will do with the drive.

I'm tempted just to bin it and not use Mtrons anymore for data drives (on 3 PCs). As most of my stuff is on remote NASs it's not such a big deal.

yefi
Posts: 134
Joined: Tue Jun 12, 2007 3:19 pm
Location: UK

Re: Mtron SSD Failure

Post by yefi » Fri Oct 03, 2008 8:51 am

victorhortalives wrote:Sounds to me like a controller failure. To their credit Mtron responded very quickly and will RMA the drive. My problem is that there is a lot of sensitive data on the drive. Will they be able to access it or not ?
You know, that's one thing that hasn't been discussed about SSD's--you can't wipe them.

The wear-levelling technology will mean that when you delete something, it isn't really deleted, and when you overwrite something, like when wiping, you can't be sure what you're overwriting.

victorhortalives
*Lifetime Patron*
Posts: 207
Joined: Wed Aug 08, 2007 1:50 am
Location: Xhystos

Mtron's Reply

Post by victorhortalives » Mon Oct 06, 2008 12:18 am

Here's Mtron's reply to my question about data security :


"

Once we receive your unit, we return to our manufactory and they will initialize defect SSD. In this process will erase all the data in flash memories.

So, please do not worry about security of your data.

Please send completed RMA form for further process. I will look forward to your reply.

"

Does this reassure me ?

m^2
Posts: 146
Joined: Mon Jan 29, 2007 2:12 am
Location: Poland
Contact:

Post by m^2 » Wed Oct 15, 2008 8:22 am

Vicotnik wrote:Best to never keep sensitive data unencrypted on any drive I suppose. TrueCrypt ftw. :)
...And then a single bit error kills all your sensitive data.

Vicotnik
*Lifetime Patron*
Posts: 1831
Joined: Thu Feb 13, 2003 6:53 am
Location: Sweden

Post by Vicotnik » Wed Oct 15, 2008 10:13 am

m^2 wrote:...And then a single bit error kills all your sensitive data.
That's why we have backups. And from the TrueCrypt FAQ:

Q: What will happen when a part of a TrueCrypt volume becomes corrupted?

A: In encrypted data, one corrupted bit usually corrupts the whole ciphertext block in which it occurred. The ciphertext block size used by TrueCrypt is 16 bytes (i.e., 128 bits). The mode of operation used by TrueCrypt ensures that if data corruption occurs within a block, the remaining blocks are not affected. See also the question 'What do I do when the encrypted filesystem on my TrueCrypt volume is corrupted?


Q: What do I do when the encrypted filesystem on my TrueCrypt volume is corrupted?

A: File system within a TrueCrypt volume may become corrupted in the same way as any normal unencrypted file system. When that happens, you can use filesystem repair tools supplied with your operating system to fix it. In Windows, it is the 'chkdsk' tool. TrueCrypt provides an easy way to use this tool on a TrueCrypt volume: First, make a backup copy of the TrueCrypt volume (because the 'chkdsk' tool might damage the filesystem even more) and then mount it. Right-click the mounted volume in the main TrueCrypt window (in the drive list) and from the context menu select 'Repair Filesystem'.

Terje
Posts: 86
Joined: Wed Sep 08, 2004 4:50 am

Post by Terje » Fri Oct 17, 2008 8:56 am

Vicotnik wrote:
AZBrandon wrote:I
Oh, I have backups. It's just that with a failing HDD I usually wipe the disk before sending it in. I hadn't thought about that one might not be able to do that with a failing SSD.
Is this really different from a HD if correctly implemented?
I would think that the SSD would allow you to access the rest of the SSD if one "block" fails.

If the controller on the SSD fails, then you are however unabled to erase it, but this would be the case if the controller fail on a HDD as well (and they do indeed fail, but it reasonably rare since the logic on controllers are usually very mature).

I believe for instance seagate had a series with SATA drives a couple of years back that tended to fail due to one component on the controller card overheating.

As pointed out by someone else, you might not be able to wipe the content anyway due to wear leveling, which is an interesting thought that I would think they need to get a solution to if it does not exist already.

andyb
Patron of SPCR
Posts: 3307
Joined: Wed Dec 15, 2004 12:00 pm
Location: Essex, England

Post by andyb » Fri Oct 17, 2008 3:21 pm

The wear-levelling technology will mean that when you delete something, it isn't really deleted, and when you overwrite something, like when wiping, you can't be sure what you're overwriting.
A thought about what "victorhortalives" could do.

Buy an identical replacement (if you dont have another to use), and swap the controller if it is possible to do so (i.e. like a standard HDD with a seperate PCB), but I expect it will all be one one PCB anyway, so my cunning plan wont work :(

My idea io working on the assumption that its the controller AND that you can swap it, all you would need to do then is use something like "File Shredder 2" and use its ability to wipe empty space using the 35-times pass, keep on doing that until you are happy, or until the drive has written so much its actually not able to write any more.


Andy

victorhortalives
*Lifetime Patron*
Posts: 207
Joined: Wed Aug 08, 2007 1:50 am
Location: Xhystos

Post by victorhortalives » Sat Oct 18, 2008 12:26 am

Current Status of this :

I didn't send it back to Mtron, so I'm going to open it up to have a look.

First I have to find a very small Torx head screwdriver (#6 or so). But I think the insides will be integrated onto one PCB.

I saw somewhere a pic of a bare unit - if I find it I'll post a link.

I already have a replacement unit (bought it on Ebay the day before !), but from now on all these are going to be used as System drives only. i.e no sensitive data.

m^2
Posts: 146
Joined: Mon Jan 29, 2007 2:12 am
Location: Poland
Contact:

Post by m^2 » Sat Oct 18, 2008 10:00 am

Vicotnik wrote:
m^2 wrote:...And then a single bit error kills all your sensitive data.
That's why we have backups. And from the TrueCrypt FAQ:

Q: What will happen when a part of a TrueCrypt volume becomes corrupted?

A: In encrypted data, one corrupted bit usually corrupts the whole ciphertext block in which it occurred. The ciphertext block size used by TrueCrypt is 16 bytes (i.e., 128 bits). The mode of operation used by TrueCrypt ensures that if data corruption occurs within a block, the remaining blocks are not affected. See also the question 'What do I do when the encrypted filesystem on my TrueCrypt volume is corrupted?


Q: What do I do when the encrypted filesystem on my TrueCrypt volume is corrupted?

A: File system within a TrueCrypt volume may become corrupted in the same way as any normal unencrypted file system. When that happens, you can use filesystem repair tools supplied with your operating system to fix it. In Windows, it is the 'chkdsk' tool. TrueCrypt provides an easy way to use this tool on a TrueCrypt volume: First, make a backup copy of the TrueCrypt volume (because the 'chkdsk' tool might damage the filesystem even more) and then mount it. Right-click the mounted volume in the main TrueCrypt window (in the drive list) and from the context menu select 'Repair Filesystem'.
Thank you, a good read.
Now I will just recommend not using True Crypt for the most valuable data as it's only gonna keep amateurs away.
Data corruption is much smaller issue than I thought.

Vicotnik
*Lifetime Patron*
Posts: 1831
Joined: Thu Feb 13, 2003 6:53 am
Location: Sweden

Post by Vicotnik » Sat Oct 18, 2008 8:34 pm

m^2 wrote:Now I will just recommend not using True Crypt for the most valuable data as it's only gonna keep amateurs away.
You have a thing against TrueCrypt? :P I was under the impression that it was quite secure. What would be the professional choice then, PGP Disk?

highlandsun
Posts: 139
Joined: Thu Nov 10, 2005 2:04 am
Location: Los Angeles, CA
Contact:

Post by highlandsun » Sat Oct 18, 2008 9:58 pm

Flash storage devices should all support a Secure Erase command that can zero out the entire drive. It's a standard command in the ATA-8 specification, nothing special/proprietary about it. MTRON for certain supports it.

m^2
Posts: 146
Joined: Mon Jan 29, 2007 2:12 am
Location: Poland
Contact:

Post by m^2 » Sun Oct 19, 2008 2:38 am

Vicotnik wrote:
m^2 wrote:Now I will just recommend not using True Crypt for the most valuable data as it's only gonna keep amateurs away.
You have a thing against TrueCrypt? :P I was under the impression that it was quite secure. What would be the professional choice then, PGP Disk?
I don't know, I have only some theory backed up by very little practice.
After some calculations it looks much better than at the first site, bruteforce breaking even 20 character passphrase might be cheaper, but it's still not good enough for the most critical data..especially that:
  • File system is more structured than text.

    16=2^4, a lot of data is aligned, I wouldn't be surprised if file system structures were too. And this helps a lot, 17 would be way more secure, likely 15 too. 255 bits would be for sure, but I guess that performance penalty could be significant.
It's definitely not something that amateur would break, professional would need quite a lot of computational power.

victorhortalives
*Lifetime Patron*
Posts: 207
Joined: Wed Aug 08, 2007 1:50 am
Location: Xhystos

Post by victorhortalives » Sun Oct 19, 2008 3:33 am

highlandsun wrote:Flash storage devices should all support a Secure Erase command that can zero out the entire drive. It's a standard command in the ATA-8 specification, nothing special/proprietary about it. MTRON for certain supports it.
Great news. How do I invoke it if my unit now reads as a 16MB drive ?

highlandsun
Posts: 139
Joined: Thu Nov 10, 2005 2:04 am
Location: Los Angeles, CA
Contact:

Post by highlandsun » Mon Oct 20, 2008 12:23 am

I guess it's been around for even longer than I thought. Try reading here http://blogs.zdnet.com/storage/?p=148

This blog has some good info too
http://ultraparanoid.wordpress.com/2007 ... rd-drives/

And if the HDDErase program doesn't work for you, you could try sending raw ATA commands to the drive yourself
http://ata-atapi.com/atademo.html

Gojira-X
Posts: 176
Joined: Sat Oct 08, 2005 9:50 am
Location: Southend, England, UK

Post by Gojira-X » Mon Oct 20, 2008 1:07 am

I always thought that using a SSD with XP SP3 was tantamount to computational suicide due XP lacking proper support SSD's.

I don't know if its is true, but I read somewhere that Vista (with indexing optimised) is able to reduce the amount of writes it does compared XP.

After looking at the external packaging of some of the SSD's on sales, i would hazard a guess that the packages are not designed to be opened and the circuit boards swapped like HDD's.

victorhortalives
*Lifetime Patron*
Posts: 207
Joined: Wed Aug 08, 2007 1:50 am
Location: Xhystos

Post by victorhortalives » Mon Oct 20, 2008 6:38 am

highlandsun wrote:I guess it's been around for even longer than I thought. Try reading here http://blogs.zdnet.com/storage/?p=148

This blog has some good info too
http://ultraparanoid.wordpress.com/2007 ... rd-drives/

And if the HDDErase program doesn't work for you, you could try sending raw ATA commands to the drive yourself
http://ata-atapi.com/atademo.html

Thanks for the links, but they're not much use as the Mtron says it is 15MB in size not 16GB. So the data I want to erase is just not accessible.

victorhortalives
*Lifetime Patron*
Posts: 207
Joined: Wed Aug 08, 2007 1:50 am
Location: Xhystos

Post by victorhortalives » Mon Oct 20, 2008 6:52 am

Gojira-X wrote:I always thought that using a SSD with XP SP3 was tantamount to computational suicide due XP lacking proper support SSD's.

I don't know if its is true, but I read somewhere that Vista (with indexing optimised) is able to reduce the amount of writes it does compared XP.

After looking at the external packaging of some of the SSD's on sales, i would hazard a guess that the packages are not designed to be opened and the circuit boards swapped like HDD's.
I've read lots of conflicting reports on what SLC SSDs can and can't stand wrt repetitive writes. The magic "50GB per day for 140 years" is quoted by some and disparaged by others. This is what the bleeding edge of technology is all about (and bleedin' annoying too).

Just to repeat, I had 2 16GB Mtrons running - one as the System drive, the other as a Data drive. It was the Data drive that failed, with very little Windows write activity (apart from Firefox - which is not insignificant)

The System drive is still fine (and now has the Firefox write activity also), but is starting to look decidedly ragged when graphed on an HDTune/HDTach benchmark. So some degradation is happening all the time.

I could setup a RAMDrive and/or move the Temp directories to the Raptor (has now replaced the Data Mtron), but how far do you go before the benefit of 0 wait time of the SSD is averaged away.

I might do the RAMDrive to see how slow the boot process becomes.

I tried using Ubuntu 8.04 on the Mtron/Raptor combo with all the /tmp, /var stuff on the Raptor and only using ext2 files on the Mtron. The system fell over after a while with file log errors etc.

I have no desire to waste effort getting Vista to work so for the moment I'll persevere with WinXp and see how long the Mtrons last.

Vicotnik
*Lifetime Patron*
Posts: 1831
Joined: Thu Feb 13, 2003 6:53 am
Location: Sweden

Post by Vicotnik » Mon Oct 20, 2008 7:05 am

victorhortalives wrote:The System drive is still fine (and now has the Firefox write activity also), but is starting to look decidedly ragged when graphed on an HDTune/HDTach benchmark. So some degradation is happening all the time.
How do you mean ragged? I've used my Mtron as a system drive (WinXP SP2) since I bought it in april this year and it still looks fresh in HDTach, at least I think so. But I do have temp and such on a ramdisk and indexing and such crap disabled. :)

victorhortalives
*Lifetime Patron*
Posts: 207
Joined: Wed Aug 08, 2007 1:50 am
Location: Xhystos

Post by victorhortalives » Mon Oct 20, 2008 7:26 am

Vicotnik wrote:
victorhortalives wrote:The System drive is still fine (and now has the Firefox write activity also), but is starting to look decidedly ragged when graphed on an HDTune/HDTach benchmark. So some degradation is happening all the time.
How do you mean ragged? I've used my Mtron as a system drive (WinXP SP2) since I bought it in april this year and it still looks fresh in HDTach, at least I think so. But I do have temp and such on a ramdisk and indexing and such crap disabled. :)
If I had a way to post images, I'd send one to you. Part of the problem may be that it is an active system drive (affects the way HDT* reports the drive).

The plot looks like a leaf edge that has been nibbled by insects. I've seen similar reports of used SSDs on other forums.
Intel may have a Firmware tool for its SSDs that straighten out the edges again (seems hard to see why it would work if the ragged edge is a wearing effect)

I'm starting again to look at disabling as much of the WinXp overheads as I can. Where can I find a good overview of what to turn off ? PageFiles have been set = Zero for years.

I looked at RamDiscs a while ago and ended up buying the FarStone Virtual Hard Drive Pro 2.0. I'll fire that up again.

yefi
Posts: 134
Joined: Tue Jun 12, 2007 3:19 pm
Location: UK

Post by yefi » Mon Oct 20, 2008 1:03 pm

m^2 wrote:16=2^4, a lot of data is aligned, I wouldn't be surprised if file system structures were too. And this helps a lot, 17 would be way more secure, likely 15 too. 255 bits would be for sure, but I guess that performance penalty could be significant.[/list]
It's definitely not something that amateur would break, professional would need quite a lot of computational power.
Hm, 128 bits is standard block size. It's the block size used by AES, which is used by the US Government. There is a problem with small block sizes versus large amounts of patterned data however. The solution to this problem involves Modes of Operation.
highlandsun wrote:I guess it's been around for even longer than I thought. Try reading here http://blogs.zdnet.com/storage/?p=148

This blog has some good info too
http://ultraparanoid.wordpress.com/2007 ... rd-drives/

And if the HDDErase program doesn't work for you, you could try sending raw ATA commands to the drive yourself
http://ata-atapi.com/atademo.html
HDDErase is produced by the Centre for Magnetic Recording Research. Not a good omen.

highlandsun
Posts: 139
Joined: Thu Nov 10, 2005 2:04 am
Location: Los Angeles, CA
Contact:

Post by highlandsun » Mon Oct 20, 2008 1:48 pm

yefi wrote: HDDErase is produced by the Centre for Magnetic Recording Research. Not a good omen.
Regardless, the Security Erase command is a standard part of the ATA command set, and MTRON drives support it.

As for the drive reporting its size as only 15MB - pretty sure that's just from a corrupted MBR. A utility like FDISK that lets you modify the disk geometry will let you correct that. But I suspect it would be irrelevant for the Security Erase command.

By the way, the Linux hdparm command also lets you issue the ATA security commands directly. I think FreeBSD's atacontrol will as well.

Post Reply