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.petersen@xxxxxxxxxx>:
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
