2018-03-07 14:51 GMT+01:00 Steffen Maier <ma...@linux.vnet.ibm.com>:
> 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)

>>                 /*
>>                  * Many devices do not respond properly to
>>                  * 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...@bues.ch> */
UNUSUAL_DEV( 0x152d, 0x0567, 0x0114, 0x0116,
"USB to ATA/ATAPI Bridge",

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?

Reply via email to