Mailinglist Archive: opensuse-kernel (87 mails)

[Greg Freemyer <greg.freemyer@xxxxxxxxx>]

On Wed, Aug 25, 2010 at 6:24 PM, Thomas Hertweck <Thomas.Hertweck@xxxxxx> 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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-kernel+help@xxxxxxxxxxxx