With the new Intel G2 SSDs coming out, I'm thinking about upgrading my hard drive. However, there seems to be an extra level of software support needed for SSD drives. From what I have read there can be performance degradation over time and other issues.

Does anyone know how well SSD drives are supported in Linux and also if there is support for the TRIM command or if it is planned?

Solid state hard drives are form fit function of a standard hard drive interface i.e IDE, SATA, SCSI etc and no additional drivers are required. Since SSDs do have a limited write/erase lifespan there are several tweaks that can be done help. If you have enough memory eliminating swap would help too. There have been tests performed that show that under normal conditions and normal usage the drive will not wear out prematurely. SSD drives have built in wear leveling logic. I am not aware of any performance degradation over time and haven't noticed any with the SSDs in my systems (mini-itx, SATA SSDs).

So, has anyone actually tried one of the new Intel G2 SSD drives? And, can you verify that TRIM is working?

Trim has been implemented in the Linux block device layer since 2.6.28. I do not know if intelligent scheduling of discard requests (which triggers the trim ATA command) has been implemented yet though.

Bump!

Does it matter if I'm using AHCI mode or IDE mode for the trim command to work properly?

Also, if the trim command isn't being initiated automatically, is there a user initiated option?

SSD based on NAND Flash memory wearing out is a "I do not know factor," so one manufacture will say something and other will say something else. If you are worried about the SSD failing, use DRAM based versions. They will last longer than NAND Flash memory and they have better performance. Unfortunately DRAM based SSD require battery back up to keep the data.

The following device could be a better alternative to NAND Flash memory based SSD.

ACARD ANS-9010
http://www.acard.com.tw/english/fb01...&type1_idno=13

I recommend use ECC memory if you want your data be reliable for a long time. If you use non-ECC memory, your data will eventually get corrupted.



The fancy "TRIM" command may not fix the issue of wearing out a NAND Flash memory based SSD less than not using the "TRIM" command. Using AHCI mode of the storage controller depends on the controller itself. Enabling AHCI for SATA controllers may penalize performance or it may not.


The disadvantage of using NAND Flash memory based SSD is data does not last longer than 10 years and wear-n-tear happens around 5 years. The wear-n-tear value assumes constant writing data every second.

Mechanical hard drives can hold data for centuries. If you treat them nice, they can last longer than ten years.

The TRIM function isn't about SSD longevity, it's about SSD write performance. So my question still stands:

Does it matter if I'm using AHCI mode or IDE mode for the trim command to work properly in linux?

Also, if the trim command isn't being initiated automatically, is there a user initiated option?

I'm using the latest Mandriva if these questions require that specific info.

You are thinking too hard about the issue. Since NAND Flash memory based SSD have a lot lower latency and the sizes of program files in Linux is small, SSD paints a better picture for loading programs up faster instead being elephant throwers. How small program files in Linux? Well, it is lower than a megabyte. Some might be close to ten megabytes. If you are scared about throughput or bandwidth stick to regular hard drives or use DRAM based SSD. One thing you should learn is that latency always rules the performance of computers, so it is best to find storage that has the lowest latency. Throughput can always be increased manually using RAID.

If you want to get answer to this question, you should ask the same question in a kernel mailing list at kernel.org. I suggest use NAND Flash memory based SSD for what it is intend which is lower latency. If you want bandwidth out of NAND Flash memory based SSD, than you have to understand about NAND Flash memory that write performance is poor. When SSD start using FRAM than everything will change because FRAM is as fast as DRAM.

Personally I can care less for NAND Flash based SSD because it is the wrong way to introduce SSD. DRAM based is still the best for SSD.

I still stand on that in order for the fancy "TRIM" command to work depends on your storage controller. Also I do think it matters what mode, but your controller have to be compatible to pass the fancy "TRIM" command. Third not all controllers are compatible with all the ATA and SATA commands.

I appreciate your thoughts on my questions Electro, but you're assuming too much about my reasons for those questions.

I'm using an Indilinx / Barefoot controlled SSD which does (pending firmware update) support the trim function. Indilinx has had some major issues with firmware problems lately specifically related to severe write performance degradation, and support for the Trim command. I'm not talking about a marginal difference in throughput here, my computer kept freezing.

Further, both AHCI and IDE modes support the Trim command generally, but I'm asking specifically about the linux implementation. For instance, in MS Windows, the default MS AHCI drivers are the only ones that do support the Trim command while the Intel, and other after-market drivers do not. Software support is just as important as hardware / firmware support.


Does it matter if I'm using AHCI mode or IDE mode for the trim command to work properly in linux?

Also, if the trim command isn't being initiated automatically, is there a user initiated option?

Another question...

Crucial (the manufacturer of my SSD) has a simple "wiper" program that can be manually run in Windows to perform the "trim" function periodically. If I ran this simple windows executable file in Wine or a virtual machine would the trim command be properly passed to the SSD?

If your computer kept on freezing, that is a different problem.

I have given you enough time to find it, but it seems you have not found it. Again not all ATA and SATA controllers supports the "TRIM" command, so again in order for the TRIM command to work you will need a storage controller that supports it.

It is easy to find the option about forcing to implement a like "TRIM" command in the kernel but you have to use at least kernel version 2.6.28. The following explains about the command in kernel version 2.6.28 and up.

http://www.kernel.org/doc/menuconfig...AL_TRIM_EXCESS

The documentation for Documentation/nommu-mmap.txt.

http://www.mjmwired.net/kernel/Docum...nommu-mmap.txt

You are being too picking what mode you should set your controller because your controller have to support it anyways. If your controller supports the "TRIM" then it does not matter what mode. Also ATA in Linux is shared with SATA by now and ATA is set as SCSI, so again it does not matter for it.

I suggest set the block size to close to 512 kilobytes to reduce penalty throughput. The only file system that supports UNIX permissions, that Linux supports, and can handle close to 512 kilobytes block size is XFS. XFS limits its block size to 64 kilobytes. Again throughput fellows behind latency because latency rules performance in computers.


Can not be done because WINE is a Windows application emulator and not a Windows driver emulator. Also using a program like VMware to run your wiper utility will not work because the whole physical drive have to be added to the virtual machine. A physical disk can not be used or mounted with Linux and be used with VMware at the same time.