On Wed, Aug 25, 2010 at 6:24 PM, Thomas Hertweck <Thomas.Hertweck@web.de> wrote:
Hi!
I asked a question on the opensuse-de mailing list and Philipp Thomas gave me a tip to better try the opensuse-kernel mailing list, so here we go:
I have started a reference page on the wiki. It needs further elaboration, but it's worth a read: http://en.opensuse.org/SDB:SSD_discard_%28trim%29_support Feel free to add some of the below to the page.
What filesystem should be used for partitions on an SSD? Or does the filesystem not really matter? Are there any special mount options that should be used? Does Linux nowadays fully support TRIM?
ext4 and xfs have internal discard support, BUT it is highly non-optimized and as such is not a significant performance benefit. The major issue is the trim commands require the command queue on the SSD be flushed. So interspersing trims with normal i/o is not a great solution. fyi: Windows also intersperses the commands, so it to does not greatly benefit. In my opinion, a better solution for now is to use the wiper.sh script described in the wiki page. wiper.sh depends on fallocate() being supported by the filesystem. Many do including ext3, ext4, xfs. Not sure which others. The big problem with wiper.sh is it has no support for lvm / dm / md setups. And worse I don't think it detects the problem, so if used with partitions on those setups it could cause data loss!
There is of course some information about these topics on the internet or in the opensuse mailing list archives, but quite a lot of information seems to be outdated or even inconsistent: Some people say the Linux kernel supports TRIM but it's not fully implemented according to the ATA-8 standard.
True. The kernel at present only provides one contiguous trim range per trim command. And it maxes out at 4GB per range iirc. The spec allows a vectorized list of non-contguous ranges to be passed in. The wiper.sh script does so, but it uses hdparm to bypass most of the block stack.
Some people say /tmp or /var should not be put on an SSD because of frequent writes.
That's a historical comment aiui.
Some people even say they had problems with SSDs under Linux in general and faced permanent timeout problems.
Don't know about that.
Some people recommend the use of special scripts (TRIM related) that seem to be part of the hdparm package, others say they are no longer required since kernel 2.6.33.
With the exception of Intel SSDs I would use the script unless you are using lvm / dm / md. The script is in oS 11.2 and 11.3 It is known to have an issue with Intel SSDs, but it does not cause data loss. The issue is that the script creates payloads of range vectors up to 1MB. The Intel chip only support 512B or range payload per trim. I am not aware of any SDD that is able to handle the kernel implementation more effectively than the script. fyi: oS 11.3 has hdparm v9.28 I just checked and v9.30 was released a couple weeks ago. Possibly it has better payload management. If it was my SSD, I would get the latest hdparm and wiper.sh for sure. I don't know if they're in OBS or not. The source is at: http://sourceforge.net/projects/hdparm/files/
I am not an expert on these issues, therefore I (and I am sure others as well) would appreciate some input from the experts regarding these questions. Thanks in advance for shedding some light on the issues.
Regards, Thomas
Greg -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org