The truth about firmware 1.4 and Linux

[bigup]

Hello all,

This post is for people using Linux that would like to upgrade their firmware to the last 1.4 version. We will try to answer questions, with the help of the OCZ community. Personally I have a Firmware version 1.10

[bigup@bigup-laptop BiGuPBox]\$ sudo hdparm -I /dev/sda
/dev/sda:
ATA device, with non-removable media
        Model Number:       OCZ-VERTEX v1.10                        
        Serial Number:      LCRH13ZYFG7AX12EJ898                    
        Firmware Revision:  1370

I saw on some posts, people saying that Linux users should use firmware 1.41 with GC (Garbage Collection) because Linux does not provide TRIM support.
This is true Linux does not supports TRIM, for example Ubuntu 9.10 Karmic does not support it. Here is the evidence.

TRIM is *not* in the Linux kernel (*any* version).
There are external patches to implement it, but they are poorly done and slow the system down immensely. Not worth using.

Various kernel developers (me included) are trying to work out a better implementation for taking advantage of TRIM on Linux.

At present, the best thing is the wiper.sh script, which you can read about in the Linux part of these forums. It works well, quickly, and is probably best run once every few days.

So, here it is again: I'm Mark Lord, the guy behind the original Linux IDE, hdparm, parts of libata, and other stuff. Yes, I'm a Linux kernel hacker (full-time).

The current kernel.org kernels do NOT implement ATA TRIM. The main reason being, we still haven't agreed upon the best way to implement some form of automatic TRIM.

So, for now, one can run wiper.sh periodically, whenever one feels their drives require TRIM. This can be better than the automatic GC firmware, because it gives you direct control over when it happens, as opposed to the firmware doing it at the exact instant of a power failure or real-time critical operation.

The wiper.sh end-result should be better than what automatic GC can achieve, since we have more info about free blocks than GC does.

So, there is no ATA Trim in the kernel.

There is a git tree available, from which patches can be generated, to add TRIM to recent kernels. It doesn't work very well, and really slows down the system. Don't bother with that.

There is also now a git tree from Chris Mason, specifically to add TRIM for the experimental btrfs filesystem. I don't recommend that, either, though it probably does work better than the earlier patches did.

Cheers

So here was my questions and the answers:

1. I Use firmware 1.10 (v1370) Why should I upgrade to 1.3 using a Windows system I don't have at all and then to 1.40 ? Can I upgrade directly to 1.40, why not ? and will I loose data ?
2. I saw that the 1.40 upgrade ISO file, use linux and Freedos to update the firmware. Can I use directly Freedos on my existing Linux system to do the upgrade ? (So any linux LiveCD could upgrade the firmware)

I think you should be able to boot a freedos CD to upgrade to 1.30 without the use of Windows (or use the harshw-iso from the sticky section ).
Then you should use the 1.4 iso to upgrade to 1.4 (or 1.41GC whichever you prefer).

Both those upgrades are non-destructive, but make sure you have proper backups in case something goes wrong.

Linux users should use the 1.4.x to use the wiper.sh script.
Thanks to people in this forum.

[b2bde4]

I think you should trust a kernel developer when he sais it's not supported yet.

TRIM is *not* in the Linux kernel (*any* version).
There are external patches to implement it, but they are poorly done and slow the system down immensely. Not worth using.

Various kernel developers (me included) are trying to work out a better implementation for taking advantage of TRIM on Linux.

At present, the best thing is the wiper.sh script, which you can read about in the Linux part of these forums. It works well, quickly, and is probably best run once every few days.

Cheers

I have done so previously with perhaps a dozen posts already in these very forums.

So, here it is again: I'm Mark Lord, the guy behind the original Linux IDE, hdparm, parts of libata, and other stuff. Yes, I'm a Linux kernel hacker (full-time).

The current kernel.org kernels do NOT implement ATA TRIM. The main reason being, we still haven't agreed upon the best way to implement some form of automatic TRIM.

So, for now, one can run wiper.sh periodically, whenever one feels their drives require TRIM. This can be better than the automatic GC firmware, because it gives you direct control over when it happens, as opposed to the firmware doing it at the exact instant of a power failure or real-time critical operation.

The wiper.sh end-result should be better than what automatic GC can achieve, since we have more info about free blocks than GC does.

So, there is no ATA Trim in the kernel.

There is a git tree available, from which patches can be generated, to add TRIM to recent kernels. It doesn't work very well, and really slows down the system. Don't bother with that.

There is also now a git tree from Chris Mason, specifically to add TRIM for the experimental btrfs filesystem. I don't recommend that, either, though it probably does work better than the earlier patches did.

Cheers

[Praz]

I think you should trust a kernel developer when he sais it's not supported yet.

Wise words indeed.

[b2bde4]

I'm currently spending some time creating a graphical user interface for wiper.sh which will hopefully automate the process of trimming the disk. A working alpha will probably be available in a week or two.

[b2bde4]

I usually get lost in the version numbering scheme used, but here is what I believe you need to do.

I think you should be able to boot a freedos CD to upgrade to 1.30 without the use of Windows (or use the harshw-iso from the sticky section ).
Then you should use the 1.4 iso to upgrade to 1.4 (or 1.41GC whichever you prefer).

Both those upgrades are non-destructive, but make sure you have proper backups in case something goes wrong.

[mlord]

I saw on some posts, people saying that Linux users should use firmware 1.41 with GC (Garbage Collection) because Linux does not provide TRIM support.
This is not true Linux supports TRIM since December 2008 ..

I sometimes do wonder where incorrect information comes from.

The link you gave talks about block layer support for the SCSI DISCARD command, which is supported by some SCSI disk arrays and SSDs (usually RAM-based).

There is still nothing in the kernel for ATA TRIM support, which is what SATA SSDs use.

Cheers

[andrewabc]

@bigup
You mention using ubuntu 9.10 for TRIM.
If you frequented the developement forum, you would notice any SSD thread talks about how ubuntu 9.10 will not support TRIM on a default install. You've been misinformed.

[bigup]

Ok thanks guys for all the information, and to help me to find what is true or not about that.
@mlord This 2.6.28 trim support info came from a (wrong) French linux news site or wikipedia
@b2bde4 thanks for pointing me to the evidence of non-support.

It's almost impossible to find verifiable information about TRIM status in the linux kernel on internet, just to explain here are some links that put me in the wrong direction :

I found that the 2.6.30 added support for TRIM in libata in this commit that does no means it's used, because you also need to use a filesystem that's sends the TRIM commands, but EXT4 has this support. So everything was ready.
Then I found a linux developer that ues an OCZ 120g drive that tested the libata trim support and saw that the drive was rejecting the commands
finally someone asked for support in Karmic, but the answer was not clear as a YES/NO

[Tony]

I am sure once Linux fully supports auto TRIM Mark will post as such here on the forum. For now you can use his TRIM tool which works very well and is (un...ish ) officially supported by OCZ here on the forum.

[mlord]

I found that the 2.6.30 added support for TRIM in libata in this commit

No it did not. That commit simply adds some definitions that someday might be used by real TRIM code. It does not add TRIM code.

EXT4 has this support

No, it has SCSI DISCARD support. Which, even when patched into libata (for SATA), does not work very well at all with TRIM. Slow as hell.

Then I found a linux developer that ues an OCZ 120g drive

Congratulations. You found me.

Here's some news, though: btrfs by Chris Mason now partially supports TRIM in the latest git, based upon my suggestions of batching lots of small TRIMs into single larger requests. I haven't looked closely to see exactly what is and isn't there, though.

Cheers

[antiram]

merged 6 days ago and is in 2.6.32-rc5, i find nothing newer
http://git.kernel.org/?p=linux/kerne...fb8e03c209f3f3

but it sends no trim with mount -o ssd,discard,noatime
tested with a patched qemu-kvm ide.c that looks like a ssd with trim
Are the old trim patches for .29 needed to get it working?

[mlord]

Like I said, I haven't looked more closely at which bits actually made it upstream.

But Chris did email me a link to his own git tree,
where apparently it all should be working:

git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git master

Cheers

[mlord]

1. hdparm / wiper.sh use only the ATA TRIM command. They don't know anything about the older method used by the MSwin wiper.exe program, and therefore cannot function on drives with official firmware before the latest 1.4 version.

2. As such, hdparm / wiper.sh can only TRIM drives that implement TRIM. So if you're using the GC-only version of the latest firmware, then wiper.sh won't work on it either.

3. I have the new 1.4 firmware (TRIM version) running on my personal development machine (120GB Vertex), as well as on an external 60GB Vertex that I regularly thrash and trash for testing purposes. There is also a 32GB barebones Indilinx factory drive here, with (older) TRIM firmware, currently in active duty as the root / database drive in my MythTV box. All of these drives have been totally rock solid with wiper.sh under Linux.

4. I confess little-to-no interest in the GC-only derivative of the firmware, and have not extensively used or tested that.

5. Users with other Vertex drive variations, eg. Vertex Turbo, should continue to encourage OCZ to release TRIM firmware for those as well. But in the meantime, lesson learned: stick to the well supported models. They're cheaper, and perform just about identically to their higher-priced siblings.

Cheers

[ruhani04]

Thx for these infos. Really helped to clarify some questions I had. I think the only question I have left is what is the real world performance difference between TRIM and GC. I know you stated that TRIM gives you better results than GC. It would be just nice to see some comparison data since people claim GC restores performance to 90plus %.

[maniacdave]

Thanks for keeping your questions clear.

I've posted the answers in one of the existing Linux threads here, so that I don't have to re-answer them again to somebody else in email/PM.

http://www.ocztechnologyforum.com/fo...9&postcount=13

Cheers!

That was fast, thank you very much!

I suspected I was getting stranded with my Turbo here. OCZ guys suggested that Turbos are regular Vertexes, with just a bit more on-spec HW, which can take the SW overclock performed by FW. Because of this, OCZ say, it is possible to flash regular Vertex FW to them. Of course we'd loose the minor speed edge we paid for.

I think that's sort of good news in case OCZ decide to ditch Turbo FW completely. So far, no Turbo FW has been released after all.

I was thinking about the whole TRIM stuff. You might be the only person I know who could tell me some valuable info...

The main crowd around SSD sees the drive as completely virtual storage, there are no real "disk" offsets, etc. When FS commits a write, it gets written "somewhere". When we eventually touch all NANDs, they are "dirty" and the drive cannot touch them, because it doesn't know which blocks are really used and which aren't. Here comes TRIM The Saviour, which is vital - the drive wouldn't know $hite where it can write. Once all blocks were touched, the drive is screwed.

I, on the other hand, think that's crazy. I've never looked into ATA specs or even low level libata stuff, but the OS still uses linear offsets to get/write whatever it needs. The drive may be remapping blocks internally, but it still has some virtual offset table. When FS is full, we can overwrite data normally, like with plate drives. So what? Sure, losing track of actually unused blocks is a performance hit for the drive's optimizing algos, but it can never grind to a halt...

You say you have a drive for thrashing - how many % of the drive's total capacity it takes to write in total (e.g. 200%?) for it to get real slow? Does it get slow at all? I get the TRIM benefit, it's actually an amazing idea, but how necessary it really is? You're in the heart of related Linux development, tell me. I'd really like to avoid rsync-out to backup repo, sanitary wipe, rsync-in every month to get the speeds they advertise.

Have you tried copying an image to your drive? That's a concern for me. Does it mark all blocks as "dirty" and require a complete wipe? That might pose a problem and require FS-level (rsync, tar, duplicity, etc) restores intead of blkdev-level (cat, dd)...

Any suggestions of best practices? Not considering the damn wiping available only to selected few...