Linus, Got completely ignored last time, so time for some Linus stylee directness ;-) This thread has moved onto a discuss of transfer limits based entirely upon "max_sectors"! It's cobblers. I'd love to hear how this applied to a SCSI tape drive, or a SCSI scanner etc - it's a disk centric concept. With no disrespect intended, disks are pretty dumb - use largely fixed transfer sizes, and but a small subset of the SCSI command set. You're not considering the "bigger picture". To succinctly re-iterate - you're breaking functionality (albeit an exploited defect), without providing a timeline / plan for it's restoration. Again I don't disagree with the plan to make this change in the medium term, once the lower levels provide large transfer capability. Surely the length of this thread is indicative of a need to go for a third option to the current in or out plans. Regards, |\ |/ave -----Original Message----- From: linux-scsi-owner@xxxxxxxxxxxxxxx [mailto:linux-scsi-owner@xxxxxxxxxxxxxxx] On Behalf Of Linus Torvalds Sent: 03 March 2006 20:10 To: Jeff Garzik Cc: Steve Byan; Mark Lord; Matthias Andree; Douglas Gilbert; Mark Rustad; linux-scsi@xxxxxxxxxxxxxxx; Linux Kernel Mailing List Subject: Re: sg regression in 2.6.16-rc5 On Fri, 3 Mar 2006, Jeff Garzik wrote: > > 256 max sectors IDE driver, 200 max sectors libata (due to driver not > hardware). When I said "lower due to broken hw" I was more thinking about things like the SiIimage driver, which actually limits the rqsize to 15 sectors due to some strange hw interactions with seagate SATA devices. (It will then raise it back up to 128 if it's not a Seagate SATA drive. I forget what the exact issue was. Some strange corruption in some limited case, and not allowing big requests worked around it. There's some strange IDE quirks out there...). Linus - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html