On Tue, Nov 10, 2009 at 9:36 AM, Martin K. Petersen <martin.petersen@xxxxxxxxxx> wrote: >>>>>> "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. Absolutely agreed: the SSD manufacturers will limit their NAND performance given the performance limitations of the controller front-end. Also, given their management layer is an on-board ASIC, they further limit their performance in this design. > > 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. I'm not talking about memory-based or -looking devices. A block device is all you need, and you don't have to re-write file systems to put one atop a block device. Those using legacy controller technology can overcome the issue by using multiple devices. We've been talking single device performance. I can get 6GB/s using 8 SSS drives. Scalability is much easier when you start with really fast individual components. So, legacy controllers are still a bad design. > > 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. And I do appreciate all your work. I fear, in this case, discard will be optimized for the slower technology... we won't be getting all that's available from it. > > Note that I don't think that memory-based SSS devices are without merit. Let's call it CPU-based. "Memory-based" sounds like RAM-based storage... we're not talking about that. > But it's baloney to claim that a storage-flavored interface inherently > means bad performance. You need an epiphany here. Between the SAS/SATA controllers and the on-board drive logic, SSD's are a bad design when it comes to performance. They are dwarfed, in performance, by CPU-based controllers. CPU's have much more performance for handling the management needed by NAND, and there are so many cores these days going unused. SSD's do win the "compatibility" argument. It's too bad we didn't invent thumb drives that were floppy compatible ;) > > > 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 Only on SSD's behind legacy controllers. It worked great as-is with SSS. > 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. Too bad the legacy design doesn't go with them ;) Chris > > 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
