Linus Torvalds (torvalds@linux-foundation.org) on 8/22/08 wrote:
---------------------------

>Do you really think that people sell enough FC disks
>that they do FC "natively"? I personally don't.
>
>Same goes for any RAID enclosure or controller. It
>serializes all the commands, buffers them up per channel,
>and does a fair amount of computation too if we're talking
>higher raid levels (ie then it needs to buffer the data
>too). It may well be able to saturate the channel, and
>not lose any IOPS (in fact, hopefully do more aggregate
>IOPS than the single channels it is doing RAID on), but
>it's going to add latency.
>
>But you may be right that it's not quite noticeable enough
>to matter.
>
>But I'd like to point out the stories from SSD manufacturers
>about how OS's aren't getting everything they should from
>SSD performance. How much do you want to bet it's because
>of the fact that the IO latency dropped by two orders of
>magnitude, and all the optimization decisions turn out to
>be wrong?
>
>And I'm just pretty sure the same thing is true when it
>comes to things like existing FC controllers.
>


I don't really know whether the FC hard drives being sold are native FC or using an FC to SCSI bridge chip, but for tape drives they definitely do sell native FC LTO drives, for instance. They cost more, though whether that's because of the low volumes (but I'd expect the volumes on FC to SCSI bridge chips aren't high either...) or because people are willing to pay more for them due to various issues the drives using FC to SCSI bridges caused is an open question.

I would guess the less than expected performance gain from SSDs so far would be mostly due to issues with block sizes in the flash device. Hard drives have been using 512 byte sectors forever for backwards compatibility and most filesystems use 1k to maybe 16k blocks at most, whereas flash devices have block sizes from 64k to 256k (maybe even more today as the size grows) You can read or write smaller than that (pages are 4k I think?) but the erases only happen in block sizes and that's what kills you for truly "random writes". A log-structured filesystem may turn out to be better for flash...

I would guess that if you created an ext3 filesystem with a 256k block size it might do noticeably better with an SSD, but the waste of space could be rather painful at current SSD prices if you have a lot of small files, like say a few thousand copies of various versions of Linux kernel source ;)