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)
If you wait about 5 hours from the time of this post then go to the
smartmontools mirror at:
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).
Assuming it is there, clone it then try to build smartmontools
( './autogen.sh ; ./configure ; make install') and try the new smartd ***.
You should get one warning per 8 TB device (for each run of smartd) and no
more.
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.
Doug Gilbert
*** without a --prefix=/usr/sbin or similar option to .configure I think
that smartd will be placed in /usr/local/sbin which may be different
from where your distro places it. Your PATH will determine which one
is used.
/*
* 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?
