>>>>> "Chris" == Chris Worley <worleys@xxxxxxxxx> writes: Chris> I'm not talking about memory-based or -looking devices. A block Chris> device is all you need, and you don't have to re-write file Chris> systems to put one atop a block device. And a SATA/SCSI-fronted flash disk isn't a block device how? Do you have any compelling evidence as to why using a protocol like SCSI is bad? A SCSI command is typically 16 bytes. A typical HBA IOCB slightly bigger but includes the inevitable scatterlist. We're talking a pretty dense format for expressing an I/O operation here. You seem to be arguing that letting a device speak "block" instead of SCSI would make things faster. I'm not convinced. Also, SCSI gives us a nice way to track outstanding I/Os via command queueing plus much more. All in a open, non-vendor-specific format requiring no custom drivers. Unlike, say, the SSS board you mentioned elsewhere in this thread. On top of that Linux is used all over the place in deployments that have throughput and IOPS figures above and beyond the numbers you quote here. Despite "legacy" controllers being in the mix. Chris> Those using legacy controller technology can overcome the issue Chris> by using multiple devices. We've been talking single device Chris> performance. I can get 6GB/s using 8 SSS drives. And adding another flash-backed SAS board isn't giving you exactly the same benefit? Chris> And I do appreciate all your work. I fear, in this case, discard Chris> will be optimized for the slower technology... we won't be Chris> getting all that's available from it. Discard isn't "optimized" for anything. It's a command. Filesystem issues it, it gets sent to the storage device (DSM/TRIM, WRITE SAME, or UNMAP depending on target type). Chris> CPU's have much more performance for handling the management Chris> needed by NAND, and there are so many cores these days going Chris> unused. You seem to think that the limiting factor in SSD design is the speed of the ASIC and not the speed of the actual flash chips behind it. Chris> SSD's do win the "compatibility" argument. It's too bad we Chris> didn't invent thumb drives that were floppy compatible ;) There are many good reasons for that. drivers/block/floppy.c contains a several of them. Keep a bag of expletives handy. >> Because initial TRIM performance was absolutely appalling Chris> Only on SSD's behind legacy controllers. It worked great as-is Chris> with SSS. Please elaborate. -- 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
