Daar zit een sterke relatie tussen. Maar ik denk dat je in de war kwam door het verschil met random en sequential:
sequential I/O -> filesystem zorgt altijd voor genoeg queued I/Os
random I/O -> het verhogen van de queue depth door het filesystem is voor reads niet mogelijk.
Queue depth bij writes is ook niet cq. minder van belang. Dit komt door write buffering; iets wat je filesystem doet en wat SSD/HDDs zelf ook doen. De HDD/SSD kan de writes ook out-of-order uitvoeren, maar moet daarbij zogenaamde 'flush' commando's gehoorzaken; die commando's zullen pas klaar zijn als alle writes naar disk zijn geschreven. Zo behouden journaling filesystems als NTFS en vrijwel alles behalve FAT hun integriteit in geval van een blauw scherm/crash of stroomstoring.
De kanalen zijn toch gewoon het aantal geheugenchips?
Nee, de kanalen is afhankelijk van de chipconfiguratie en de controller. Intel heeft 10 kanalen voor de normale serie en 5 kanalen voor de X25-V serie. Dat betekent echter niet dat er maar 10 of 5 chips op de SSD kunnen zitten. Diverse technieken als toggle/sync/DDR NAND worden gebruikt om meerdere chips op één kanaal te koppelen.
Elk kanaal kun je zien als een losse SSD zonder controller; de NAND controller is een soort intelligente hardware RAID0 die het principe van striping toepast op meerdere NAND kanalen. De performance hiervan is nagenoeg gelijk dan wanneer je enkelkanaals-SSDs aansluit en software RAID0 zou doen. USB sticks en dergelijke zijn vaak single channel; dan zie je 22MB/s en 7MB/s write bijvoorbeeld.
Neem nu 10 kanalen bij de Intel X25-M:
10* 22MB/s = 220MB/s sequential read
10* 7MB/s = 70MB/s sequential write
Zo werkt dat heel simpel, voor random I/O is het veel ingewikkelder.
Dus zelfs met een qd=32 is het mogelijk dat maar 1 kanaal wordt aangesproken als je de pech hebt dat alle data op één NAND chip staat.
Inderdaad; net als RAID0. Vandaar dat in CDM en AS SSD benchmarks het verschil tussen 4K read en 4K QD32 read altijd maximaal een factor is van het aantal kanalen. Dus bij Intel X25-M heb je 10 kanalen en dus zal de 4K QD32 read maximaal 10 keer hoger zijn dan de normale 4K score. Dit is in de praktijk iets minder door het effect dat de verdeling van reads niet optimaal is. Hoe hoger de queue depth, des te lager de performancedegradatie van dit fenomeen. Anders had je aan QD=10 genoeg.
De kans dat je alle kanalen aanspreekt met één enkele grote I/O request is veel groter omdat de kans dat de data netjes verdeeld is over de verschillende kanalen zeer groot is.
Sequential I/O gebeurt niet door één groot request maar door meerdere requests die opeenvolgend zijn. Standaard is de max request size voor sequential I/O 128KiB. Dus als je een 40 gigabyte bestand inleest of wegschrijft, gebeurt dat met opvolgende 128KiB requests.
Jouw stelling dat raw I/O betekent dat maar 1 kanaal wordt aangesproken klopt dan ook niet. Anders zou je in HD Tune nooit boven de 25MB/s geraken.
Dat klopt ook; zie de benchmark hierboven met Random access. Dat HDTune 40MB/s ipv 20MB/s aangeeft komt doordat HDtune plekken leest die nog niet eerder zijn beschreven, en daardoor de latency ook stukken lager is. Dit verhoogt kunstmatig de random access scores die HDtune geeft. Zou je de hele schijf volgooien met data, zou je in HDtune random access max 20MB/s ofzoiets in de 4K moeten krijgen.
Dat is ook mooi te zien in de random 1 MB test in HD Tune. Daar wordt al bijna de maximale snelheid gehaald met random read I/O terwijl qd=1.
Ja, echter dit type I/O komt in de praktijk niet voor. Dus dit blijft uiterst kunstmatig. Het zou je in principe dezelfde performance geven als 128K met 8 blocks read-ahead (1MiB read-ahead; standaard bij véél OSen).
Raw I/O is trouwens het enige wat een SSD begrijpt. Een bestandssysteem vertaalt file I/O naar raw I/O. De optimalisaties die het bestandssysteem doet zijn nagenoeg irrelevant voor benchmarking. Benchmarks gaan namelijk de performantie in ideale omstandigheden testen (logisch, ander test je eerder het systeem en niet de SSD) terwijl de optimalisaties in het bestandsysteem eerder effectief zijn in niet-optimale omstandigheden.
Oneens.

Neem bv. de read-ahead cache. Een programma leest een stukje van een bestand in, doet een aantal bewerkingen en leest dan het volgende stukje van het bestand.
Dat kan, maar is niet een doorsnee scenario. Je gaat ervanuit dat het programma al gelijk wat met de data gaat doen terwijl het bestand nog wordt ingelezen. Dat hoeft zeker niet altijd zo te zijn en veel vaker wordt er pas wat gedaan als de file totaal is ingelezen. Een uitzondering hierop zijn torrent clients die aan hashing doen bijvoorbeeld.
Overigens kan je hardeschijf maximaal met 7,5MB/s lezen zonder read-ahead. Eén 128K request per rotatie. Read-ahead is zo cruciaal dat het driedubbel-op wordt uitgevoerd:
- in de hardeschijf zelf
- in je Intel RST driver (optioneel)
- door het filesystem
Voor benchmarks heeft dit geen positieve invloed aangezien er bijna geen vertraging is tussen het sturen van de leesopdrachten.
Het feit dat je bij een hardeschijf niet gelijk meer dan 128K leest, betekent dat zodra je de volgende block wilt lezen je een rotatie hebt gemist en dus moet wachten op gemiddeld de helft van een rotational delay. Bij SSDs werkt dit natuurlijk anders en kan het zijn dat er door de SSD zelf intern geen read-ahead meer wordt toegepast. Dit durf ik echter niet met zekerheid te stellen.