From: Lutz Vieweg <lvml@5t9.de>
To: linux-raid@vger.kernel.org
Subject: Re: Software RAID and TRIM
Date: Wed, 20 Jul 2011 14:25:36 +0200 [thread overview]
Message-ID: <j06hg0$gdv$1@dough.gmane.org> (raw)
In-Reply-To: <1311164022.2031.0.camel@werner-t410>
On 07/20/2011 02:13 PM, Werner Fischer wrote:
> There is a paper from Intel "Over-provisioning an Intel® SSD" (analyzing
> X25-M 160 GB Gen.2 SSDs):
> http://cache-www.intel.com/cd/00/00/45/95/459555_459555.pdf
>
> On page 10 of this Intel presentation they mention that a spare area
>> 27% of native capacity has diminishing returns for such an SSD:
> http://maltiel-consulting.com/Enterprise_Data_Integrity_Increasing_Endurance.pdf
(This latter document is password protected.)
The first document, though, claims almost linear benefit (regarding IOs/sec)
from much higher amounts of over-provisioning. Alas, their chart does not extend
into the region where saturation of the effect must occur for sure.
Regards,
Lutz Vieweg
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-07-20 12:25 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-28 15:31 Software RAID and TRIM Tom De Mulder
2011-06-28 16:11 ` Mathias Burén
2011-06-29 10:32 ` Tom De Mulder
2011-06-29 10:45 ` NeilBrown
2011-06-29 11:10 ` Tom De Mulder
2011-06-29 11:48 ` Scott E. Armitage
2011-06-29 12:46 ` Roberto Spadim
2011-06-29 12:46 ` David Brown
2011-06-30 0:28 ` NeilBrown
2011-06-30 7:50 ` David Brown
2011-06-29 13:39 ` Namhyung Kim
2011-06-30 0:27 ` NeilBrown
2011-07-17 22:11 ` Lutz Vieweg
2011-07-17 21:57 ` Lutz Vieweg
2011-06-29 10:33 ` Tom De Mulder
2011-06-29 12:42 ` David Brown
2011-06-29 12:55 ` Tom De Mulder
2011-06-29 13:02 ` Roberto Spadim
2011-06-29 13:10 ` David Brown
2011-06-30 5:51 ` Mikael Abrahamsson
2011-07-04 9:13 ` Tom De Mulder
2011-07-04 16:26 ` Werner Fischer
2011-07-17 22:31 ` Lutz Vieweg
2011-07-17 22:16 ` Lutz Vieweg
2011-07-17 22:00 ` Lutz Vieweg
2011-06-28 16:17 ` Johannes Truschnigg
2011-06-28 16:40 ` David Brown
2011-07-17 21:52 ` Lutz Vieweg
2011-07-18 5:14 ` Mikael Abrahamsson
2011-07-18 10:35 ` David Brown
2011-07-18 10:48 ` Tom De Mulder
2011-07-18 18:09 ` Lutz Vieweg
2011-07-18 20:18 ` David Brown
2011-07-19 9:29 ` Lutz Vieweg
2011-07-19 10:22 ` David Brown
2011-07-19 13:41 ` Lutz Vieweg
2011-07-19 15:06 ` David Brown
2011-07-20 10:39 ` Lutz Vieweg
2011-07-19 14:19 ` Tom De Mulder
2011-07-20 7:42 ` David Brown
2011-07-20 12:20 ` Lutz Vieweg
2011-07-20 12:13 ` Werner Fischer
2011-07-20 12:25 ` Lutz Vieweg [this message]
2011-07-18 10:53 ` Tom De Mulder
2011-07-18 12:13 ` Werner Fischer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='j06hg0$gdv$1@dough.gmane.org' \
--to=lvml@5t9.de \
--cc=linux-raid@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.