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
