Yeah
I am in touch with scsi mantainers
I have already suggested to lower it to KERN_DEBUG, not really pushed
it, but they have said that from their perspective, this is a
sub-optimal read_capacity path taken, that shall be logged
Also, since this flag is named "try_rc_10_first" I have also suggested
that once the read_capacity_16 succeed and the attached device needs
the rad_capacity_16 due to large capacity, the scsi subsystem could
set this flag to 0 internally, but I am not sure how they feel about
this (if feasible), I am waiting for an answer
Bye
2018-03-09 17:29 GMT+01:00 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>:
> On Fri, 9 Mar 2018, Menion wrote:
>
>> Hi all
>> I am discussing about an issue I get with my Orico USBtoSATA 5 bays enclosure
>> The issue is that every 5 minutes the BTRFS perform a revalidate
>> action that will fill the dmesg with this log:
>>
>> [ 98.917660] sd 0:0:0:1: [sdb] Very big device. Trying to use READ
>> CAPACITY(16).
>> [ 99.057592] sd 0:0:0:0: [sda] Very big device. Trying to use READ
>> CAPACITY(16).
>> [ 99.304848] sd 0:0:0:2: [sdc] Very big device. Trying to use READ
>> CAPACITY(16).
>> [ 99.465374] sd 0:0:0:3: [sdd] Very big device. Trying to use READ
>> CAPACITY(16).
>> [ 99.669241] sd 0:0:0:4: [sde] Very big device. Trying to use READ
>> CAPACITY(16).
>>
>> After some investigation I think I have found out the reason
>> The sd_read_capacity in scsi layer check if read_capacity_10 or
>> read_capacity_16 should be used
>> It does it based on what this function return:
>>
>> static int sd_try_rc16_first(struct scsi_device *sdp)
>> {
>> if (sdp->host->max_cmd_len < 16)
>> return 0;
>> if (sdp->try_rc_10_first)
>> return 0;
>> if (sdp->scsi_level > SCSI_SPC_2)
>> return 1;
>> if (scsi_device_protection(sdp))
>> return 1;
>> return 0;
>> }
>>
>> the problem is that in the usb to scsi glue layer, the try_rc_10_first
>> is picked like this:
>>
>> /*
>> * Many devices do not respond properly to READ_CAPACITY_16.
>> * Tell the SCSI layer to try READ_CAPACITY_10 first.
>> * However some USB 3.0 drive enclosures return capacity
>> * modulo 2TB. Those must use READ_CAPACITY_16
>> */
>> if (!(us->fflags & US_FL_NEEDS_CAP16))
>> sdev->try_rc_10_first = 1;
>>
>> Are we sure this is the correct option? I mean to me the default
>> should be to go for rc_10 if there is a specific request in the
>> unusual devices, rather then if we dont' need cap16 we go for it,
>> like:
>>
>> if ((us->fflags & US_FL_NEEDS_CAP10))
>> sdev->try_rc_10_first = 1;
>>
>> What you think about?
>
> I think there used to be a lot of USB devices which would work with
> READ CAPACITY 10 but would not work with READ CAPACITY 16. The
> situation may not be quite so bad nowadays, but I would still prefer to
> have the kernel try RC10 first in all cases except when the NEEDS_CAP16
> flag is set.
>
> As for the the SCSI messages filling your log every 5 minutes, perhaps
> the SCSI maintainers could be convinced to change that message to be
> debug level. It would still occupy space in the kernel's log buffer,
> but by default it would be ignored by userspace logging programs.
>
> If we changed the strategy the way you suggest, we would probably get a
> lot of errors from older devices that don't support RC16. Some of them
> might even crash when they receive the command, which would make them
> unusable until a NEEDS_CAP10 flag entry was created for them.
>
> Or to put it another way, I think the population of devices which
> misbehave when they receive RC16 is probably larger than the population
> of devices which misbehave when they receive RC10. :-)
>
> Alan Stern
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
