David B:
Thanks for your interest.
In practice, I haven't yet proven that any of my devices actually do benefit from a max GB/cdb greater than 0.000065536 while an fs is mounted ...
You mean, 64 KByte/request?
Probably yes. Sorry I don't know what a "request" is. Do you already know what a "cdb" is? In usbmassbulk_10.pdf notation, the cdb (aka CDB) is the bCBLength bytes of the bCBWCB.
A request in the disk I/O queue in this case corresponds to a CDB, when it gets handled a usb-storage device. I try to avoid using overly specific jargon.
I'm saying I see cdb's commonly choked off at a max of 64 KiB each in Windows, and I hear Matt D proposing, for the sake of broader interoperability, we copy that limit into Linux and make its workaround obscure. I'm saying that limit necessarily multiplies command + status overhead by exponentially increasing numbers as the size of the typical shattered stream grows exponentially with the passing of years.
Actually 64 KB wouldn't bother me as much as the smaller numbers he also suggested, including 16 KB or 8 KB. Those sorts of numbers would make for a lot more trouble. (And I don't think he suggested making the workaround obscure, although that would necessarily be the effect since almost nobody would use it.)
Not that such a number would be very efficient for high speed devices ... and as I said, I don't much like the notion of deliberately slowing down Linux _for all hardware_ just because some cheap vendors are excessively cheap with respect to testing.
You're quite right that as time passes, and OS software matures (like Linux 2.6!), issuance of large I/O requests becomes more common ... hard to increase throughput otherwise.
I'm curious what the relevant number is for IDE or SATA... and how disk and page caching affect it.
Me too.
I hear part of the drive behind SATA command queueing is to work around the bytes/cdb chokehold in the host. I notice PCI ATA nominally forces the driver to preallocate and pin all the data of a cdb before beginning the cdb, yuck. For a max of 64 Ki - 1 blocks at 2 KiB/block that could be 128 MiB - 2 KiB.
If there is such a host side "chokehold", it seems to be entirely coming from OS software written by a company not far from Vancouver.
Things like MKFS (and badblocks) certainly like to issue much bigger requests.
mkfs is rare?
man badblocks I will now enjoy, thank you.
Most folk access "badblocks" from mkfs, which is indeed rare.
- Dave
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
