On 03/08/2018 11:34 AM, Menion wrote:
I did some more test
This log is specific from the function sd_read_capacitysd_revalidate_disk
From what I can see, it seems that it is called only when probing
newly attached devices
A quick look in the code I see that it is called by sd_revalidate_disk
This function is registered by fops for the scsi device or called
directly by sd_probe (via sd_probe_async)
So, assuming that there is no disconnection ad USB level (and it is
not since I don't get any log of it), the question is: how can trigger
a probe or call the sd_revalidate_disk?
Can it be the filesystem?
echo 1 > /sys/class/scsi_device/.../device/rescan
?
That's what I meant with "sdev _rescan_" in my previous mail.
Not sure what call paths lead to sd_revalidate_disk().
2018-03-08 11:10 GMT+01:00 Menion <menion@xxxxxxxxx>:
Anyhow, I checked something that I should have checked since the beginning.
I have stopped smartd and I still get this log, so it is something
else doing it, but does anyone have an idea how understand what
subsystem is calling again and again the read_capacity_10?
ftrace: kernel function trace
[https://lwn.net/Articles/365835/, https://lwn.net/Articles/366796/]
or dynamically attach a kprobe
[https://www.kernel.org/doc/Documentation/trace/kprobetrace.txt]
to see which process calls this (indirectly)
2018-03-08 10:16 GMT+01:00 Menion <menion@xxxxxxxxx>:
I have tried it, but it does not work:
[ 39.230095] sd 0:0:0:0: [sda] Very big device. Trying to use READ
CAPACITY(16).
[ 348.134002] sd 0:0:0:0: [sda] Very big device. Trying to use READ
CAPACITY(16).
[ 657.963478] sd 0:0:0:0: [sda] Very big device. Trying to use READ
CAPACITY(16).
2018-03-07 18:14 GMT+01:00 Douglas Gilbert <dgilbert@xxxxxxxxxxxx>:
On 2018-03-07 09:02 AM, Menion wrote:
2018-03-07 14:51 GMT+01:00 Steffen Maier <maier@xxxxxxxxxxxxxxxxxx>:
On 03/07/2018 09:24 AM, Menion wrote:
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
Is it possible that it is smartd? It is the only daemon that could do
some low level access to the device (bypassing the filesystem)
https://github.com/mirror/smartmontools
To check it is the revision (svn rev >= 4718) you need for this fix, look
at the top of the ChangeLog file and look for today's date (20180307).
Currently smartmontools only has a quirks database (and it is large)
for ATA devices, not real or pseudo SCSI device, nor NVMe devices (yet).
Hopefully this fix will be sufficient.
If it does not work, please send me the details.
/*
* 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
It seems that the bridge does have an entry in unusual_devs.h:
/* Reported by Michael Büsch <m@xxxxxxx> */
UNUSUAL_DEV( 0x152d, 0x0567, 0x0114, 0x0116,
"JMicron",
"USB to ATA/ATAPI Bridge",
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_BROKEN_FUA ),
VID:PID is 0x152d 0x0567, not sure what are the other two numbers, so
I went back and used another enclosure with same USB to SATA bridge.
The strange thing is that this other enclosure goes in UAS mode while
the one for which I am reporting the issue goes in usb-storage mode
because it gets somehow the quirks 0x50000000
Unfortunately I cannot move these 5 HDDs in the other enclosure. So do
you think that it shall be reported to linux-usb maybe?
--
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
