On 03/07/2018 09:24 AM, Menion wrote:
By flooded I mean that it continously fill the dmesg log with no
interruption, check attached a log that I have just taken from my
server
Some more details on my setup. I have these 5 HDD, WD RED 8TB in an
Orico 5 bay enclosure, running JMS567 USBtoSATA bridge and an internal
SATA multiplexer
This is connected to the USB 3.0 host port of my server, it is an Intel Atom


2018-03-07 3:45 GMT+01:00 Martin K. Petersen <martin.peter...@oracle.com>:
Also, what kind of controller are these disks attached to? The reason
you see these messages is that to the kernel it looks like a legacy disk
device that predates capacities in the TB range. The warnings are logged
because we're surprised to be going down this path based on what the
device has previously told us.

Of course Martin's statement regarding the occurrence holds true.

It does not look like continuously flooding, but rather like a repetition at some not even high frequency. Do you have some user space periodically performing SCSI target or SCSI device rescans?
Each repetition is per drive, i.e. a junk of 5 messages in your case.

[    4.929517] sd 0:0:0:0: [sda] Very big device. Trying to use READ 
CAPACITY(16).

first occurrence after initial probing

[    4.933893] sd 0:0:0:0: [sda] Very big device. Trying to use READ 
CAPACITY(16).
[    4.946474] sd 0:0:0:0: [sda] Very big device. Trying to use READ 
CAPACITY(16).

looks like we go through the code path more than once during initial probing

[   99.057592] sd 0:0:0:0: [sda] Very big device. Trying to use READ 
CAPACITY(16).

[  409.335119] sd 0:0:0:0: [sda] Very big device. Trying to use READ 
CAPACITY(16).

[  719.760106] sd 0:0:0:0: [sda] Very big device. Trying to use READ 
CAPACITY(16).

[ 1018.089562] sd 0:0:0:0: [sda] Very big device. Trying to use READ 
CAPACITY(16).

[ 1328.086120] sd 0:0:0:0: [sda] Very big device. Trying to use READ 
CAPACITY(16).

...

but from then on, you only get it roughly once every 300 seconds, i.e. 5 minutes

that's where I suspect user space as trigger, unless there is a kernel feature I'm not aware of doing such sdev rescans

preventing this would be a workaround

assuming the Linux check is correct, the proper fix might be that the device should present itself according to standards such that Linux silently uses READ CAPACITY(16) in the first place

static int sd_try_rc16_first(struct scsi_device *sdp)
{
        if (sdp->host->max_cmd_len < 16)
                return 0;

option

        if (sdp->try_rc_10_first)
                return 0;

option

        if (sdp->scsi_level > SCSI_SPC_2)
                return 1;
        if (scsi_device_protection(sdp))
                return 1;
        return 0;

option

}

just picking one arbitrary option and not being entirely sure that's the code path but you mentioned USB to SATA bridge, it might be related to:

*** drivers/usb/storage/scsiglue.c:
slave_configure[239]           sdev->try_rc_10_first = 1;

                /*
                 * 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;

if that's the cause, maybe an entry in drivers/usb/storage/unusual_devs.h would help, but that's really just guessing as I'm not familiar with USB

--
Mit freundlichen Grüßen / Kind regards
Steffen Maier

Linux on z Systems Development

IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschaeftsfuehrung: Dirk Wittkopp
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

Reply via email to