>>>>> "Chris" == Chris Worley <worleys@xxxxxxxxx> writes: Chris> I'm not saying the SCSI protocol is bad, I'm saying the Chris> SAS/SATA/SCSI controllers, that have been optimized for years for Chris> rotating media, don't have the compute power to handle the sort Chris> of performance attainable with SSS. And I'm saying that at least in the SCSI case that's untrue. SAS and FC controllers are optimized for lots and lots of I/O because their main application is driving large storage arrays which have performance comparable to the solid state devices you mention. In fact, many deployments use said SCSI controllers to drive RAM-based solid state storage devices which are faster than the flash-based devices we're talking about here. Chris> Unless you try to coalesce it for a later time, which is what I Chris> hear is being done to compensate for slow controllers. We don't coalesce. Chris> True. They limit the NAND performance based on the lack of Chris> performance of their ASIC and the controller. Interesting theory. I'm personally of the conviction that cheap SSDs suffer from amazingly poor FTL design rather than inherent hardware limitations. That's something intel got right with their drives. The hardware itself is pretty unremarkable. Chris> That doesn't mean you can't get a lot better performance out of Chris> NAND, it just means they limited themselves to be compatible, and Chris> the kernel will implement a strategy that will optimize for the Chris> poor design. You are confusing limitations in interconnect technology with the properties of the protocols used. There is no point in adding channels behind the ASIC to drive 12 Gbps of I/O if your host interface is 1.5 Gbps SATA. That has nothing to do with whether ATA and SCSI are suitable protocols. I'm arguing that the at least SCSI is a good protocol for sending commands to a block device. Nothing prevents your flash-based block device from presenting a PCIe SCSI interface to the host and then do something completely different in the back. There's lots of warts in SCSI. And I personally think that ATA TRIM was very poorly defined. But I don't believe that these protocols are inherently bad for driving storage. And I don't believe that coming up with a custom "block" interface will improve anything in the short term. Heck, the overhead of speaking SCSI is so low that even the thumb drive you brought up implements it. At negligible cost. Chris> but you also believe the best way to do SSS was behind compatible Chris> legacy SAS/SATA devices optimized for old rotating media? You're the one claiming these "legacy" devices are optimized for rotating media. I'm claiming there's nothing rotating about either protocol. Both express "do something to this range of blocks" in 16 bytes or less + a scatterlist describing memory. That's a pretty efficient interface in my book. Chris> I'd run IOZone and fill the drive (as I recall ~200GB) w/ files Chris> and benchmark, which, at the end, IOZone would delete all the Chris> files created (in the hundreds), and the delete/discard process Chris> was no more time consuming than just the delete process (for Chris> everything on the drive). This was w/ the original 2.6.27 and Chris> 2.6.28 ext4 "discard" implementations. And which device was this? How did it implement discard? -- 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
