>>>>> "Chris" == Chris Worley <worleys@xxxxxxxxx> writes: Chris> The only problem is SSD's put Solid State Storage (SSS) behind Chris> SATA/SAS controllers... while compatible w/ old disk technology, Chris> it severely limits performance (i.e. none of these SSD drives do Chris> even 300MB/s... while SSS drives do 800MB/s). You are arguing that the SATA/SCSI protocols are inhibiting factors on the grounds that PCIe solid state devices are faster. Performance inside a flash device is gated by the number of channels you run in parallel. There is not much point in increasing the number of channels if your physical interconnect (3Gbps SATA, say) can't handle the traffic. Hence the drive towards 6Gbps interconnects and beyond for both SATA and SAS. Also, not all SSS boards present a memory-style device to the host. Several shipping SSS boards use a regular SAS HBA backed by multiple SATA/SAS targets which again comprise of multiple flash channels. And the performance of these devices is absolutely on par with the memory-based devices. Without requiring proprietary drivers, and without reinventing filesystems and I/O stack. We have been pushing tens of gigabytes per second through the storage stack for years when connected to arrays which - given their large non-volatile caches - are virtually indistinguishable from SSDs. We're constantly tweaking and tuning. Jens has done a lot of work to bring down command latency, I have worked on storage topology which allows us to uniquely identify the characteristics of the physical storage device so we can issue I/O in an optimal fashion. Note that I don't think that memory-based SSS devices are without merit. But it's baloney to claim that a storage-flavored interface inherently means bad performance. Chris> So it looks like "design by committee" Linux is well behind Chris> Windows 7, while Linux contemplates slowing new technology down Chris> to optimize for ill-designed SSD's. We're not slowing anything, nor are we optimizing for ill-designed SSDs. Because initial TRIM performance was absolutely appalling there was a lot of discussion about the merits of doing weekly scrubs instead of issuing TRIM on the fly. However, Windows 7 shipped issuing TRIM in realtime which means that all the early SSDs with lame duck DSM performance are headed straight for the garbage bin. Futhermore, unlike Windows 7 we can't pretend everything is desktop class ATA. We've spent a lot of time making sure that our block layer discard support works equally well for both ATA DSM (TRIM) as well as SCSI WRITE SAME and UNMAP used by high-end arrays. All three commands have been moving targets and none of them are technically set in stone in their respective standards bodies yet. So I think it would be a stretch to claim that TRIM is well tested and stable in the industry. intel just pulled their latest X25-M firmware because of problems with Windows 7... -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
