Alan Stern wrote: > On Mon, 19 Feb 2007, Douglas Gilbert wrote: > >> Alan, >> The SG_GET_RESERVED_SIZE ioctl is also defined in >> the block layer, see block/scsi_ioctl.c . > > Ah, I didn't know that. (Or more likely, I used to know and have since > forgotten.) Thanks for pointing it out. > >> I suspect it is just a kludge to fool cdrecord that it >> is talking to a sg device. [One of many kludges in the >> block SG_IO ioctl implementation to that end.] >> So perhaps the block layer versions of SG_SET_RESERVED_SIZE >> and SG_GET_RESERVED_SIZE need to be similarly capped. > > Yes. In fact one of them already is, but the other should be too. > >> Actually I think that I would default SG_GET_RESERVED_SIZE to >> request_queue->max_sectors * 512 in the block layer >> implementation (as there is no "reserve buffer" associated >> with a block device). > > Okay. > > Come to think of it, the reserved_size value used when a new sg device is > created should also be capped at max_sectors * 512. Agreed? I can't see > any reason for ever having a larger buffer -- it would be impossible to > make use of the extra space.
Alan, That depends whether or not max_sectors can be changed (via sysfs) subsequent to a sg device being created. And I think it can. # ls -l /sys/block/sdc/queue/ total 0 drwxr-xr-x 2 root root 0 Feb 19 18:29 iosched -r--r--r-- 1 root root 4096 Feb 19 23:41 max_hw_sectors_kb -rw-r--r-- 1 root root 4096 Feb 19 23:41 max_sectors_kb -rw-r--r-- 1 root root 4096 Feb 19 23:41 nr_requests -rw-r--r-- 1 root root 4096 Feb 19 23:41 read_ahead_kb -rw-r--r-- 1 root root 4096 Feb 19 23:41 scheduler # cat max_hw_sectors_kb > max_sectors_kb ... is the real maximum if the LLD that set max_hw_sectors_kb is to be believed (actually it is often a finger in the wind). Doug Gilbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/