Does that mean we won't be able to squeeze the juice out of Intel's
Extreme SSDs on Linux?

What about those of us who use OpenFiler and build their own storage
solutions? We won't be able to provide solutions based on these SSDs
because the kernel support is crap?

I may have clients wanting to mix between SAS/SATA & SSD to load their
main database on the SSDs, but now it seems pointless since the
performance isn't gonna be that great :/

On Tue, Nov 10, 2009 at 6:39 PM, Chris Worley [off-list ref] wrote:

On Tue, Nov 10, 2009 at 2:42 AM, Kasper Sandberg [off-list ref] wrote:

quoted

On Mon, 2009-11-09 at 09:59 -0700, Chris Worley wrote:

quoted

On Mon, Nov 9, 2009 at 9:42 AM, Majed B. [off-list ref] wrote:

quoted

Well, SATA uses SCSI emulation so I guess that's no problem, right?

The only problem is SSD's put Solid State Storage (SSS) behind
SATA/SAS controllers... while compatible w/ old disk technology, it
severely limits performance (i.e. none of these SSD drives do even
300MB/s... while SSS drives do 800MB/s).  While the initial 2.6.27

No, around 280MB/s... and obviously they dont do more, because of the
simple limitation of the sata controllers.. this also means they dont
need to do as many channels as other devices..

I'm not sure if you're agreeing or disagreeing here...
280MB/s<300MB/s, due to the "compatibility" based design of SSD's,
while SSS, w/o a legacy controller, can do 800MB/s out of a single
drive.

quoted

quoted

drivers and ext4 "discard" worked very well with forward-thinking SSS
not encumbered by old controller technology... but, SSD's were not
able to handle it well:

http://lwn.net/Articles/347511/

So it looks like "design by committee" Linux is well behind Windows 7,

And how exactly does windows 7 handle this so much better?

TRIM is in W7; NTFS support.  No Linux distro does.  And by the time
"design by committee" gets through with it,we shouldn't have bothered.

quoted

quoted

while Linux contemplates slowing new technology down to optimize for
ill-designed SSD's.

It does?

Those that speak loudest in the kernel development (and contribute the
most) work for companies like Intel that promote the slower,
controller-based, SSD's.

Chris

quoted

quoted

Be glad "thumb drives" didn't try to be floppy-drive-compatible!!!

Chris

quoted

On Mon, Nov 9, 2009 at 7:37 PM, Chris Worley [off-list ref] wrote:

quoted

On Sun, Nov 8, 2009 at 6:13 PM, Majed B. [off-list ref] wrote:

quoted

The firmware which introduced the TRIM command was deemed buggy and
has been pulled out.

Are there any filesystems that are TRIM-aware?

Ext4 (at that level in the kernel, it's referred to as "discard", it's
not TRIM until it's issued as a SCSI command).

Chris

quoted

On Sun, Nov 8, 2009 at 8:57 PM, Bill Davidsen [off-list ref] wrote:

quoted

For those of us playing with use of SSD for journals on ext[34], this does
have implications for RAID performance.

http://hardware.slashdot.org/story/09/10/27/1427209/Intel-Updates-SSDs-Supports-TRIM-Faster-Writes

--
Bill Davidsen [off-list ref]
 Unintended results are the well-earned reward for incompetence.


--
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

--
      Majed B.
--
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

--
      Majed B.

--
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

-- 
       Majed B.
--
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