http://bugzilla.kernel.org/show_bug.cgi?id=12207 oshida@xxxxxxxxxxx changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |oshida@xxxxxxxxxxx --- Comment #27 from oshida@xxxxxxxxxxx 2009-04-10 09:48:44 --- Thanks for reading. Please share that this is just for tape device. > You'll have to trace this down by yourself. Yes of course, but this is not a matter for me because I was satisfied with 4MB limit. #Via SAS interface, the block size limit for tape device is 4MB w/o any configurations. #It can be also one of the reason to apply the value for me. ##On Solaris 10, it is larger than 4MB and I've not found the limit. > Where did your limit come from? Just above experiments. But 4MB (or twiced 8MB) is not my recommend. For reguralizing I hope you to decide which is reasonable value. Generally, there is no device which can operate the block size larger than 0xffffff bytes. This is from the SCSI tape device specification. (T10/SSC) > Why do you want to do this? The attribute is named "max_sectors", so > shouldn't it return the value of max_sectors? I can agree your suggestion but then I need declaring the read only attribute named "max_hw_sectors". I don't know the restrictions arround scsi driver stacks, ex, what max_sectors is used for and max_hw_sectors is used for. But by simple image, if a really effective value can be set onto a variable, it should be verifiable by reading same variable. > Did you know that max_sectors can also be changed through the block > interface? I'm sorry I did not. Thanks for teaching. But I could not find the device (of course tape drive) under that tree. I think that is just for kinds of block device which can be manipulated with T10/SBC command set. Sincerely, Teruo Oshida -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. -- To unsubscribe from this list: 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
