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? Bye 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? > > 2018-03-08 10:16 GMT+01:00 Menion <menion@xxxxxxxxx>: >> Hi >> 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). >> [ 39.338032] sd 0:0:0:1: [sdb] Very big device. Trying to use READ >> CAPACITY(16). >> [ 39.618268] sd 0:0:0:2: [sdc] Very big device. Trying to use READ >> CAPACITY(16). >> [ 39.762801] sd 0:0:0:3: [sdd] Very big device. Trying to use READ >> CAPACITY(16). >> [ 39.901059] sd 0:0:0:4: [sde] 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). >> [ 348.231327] sd 0:0:0:1: [sdb] Very big device. Trying to use READ >> CAPACITY(16). >> [ 348.353151] sd 0:0:0:2: [sdc] Very big device. Trying to use READ >> CAPACITY(16). >> [ 348.549558] sd 0:0:0:3: [sdd] Very big device. Trying to use READ >> CAPACITY(16). >> [ 348.722858] sd 0:0:0:4: [sde] 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). >> [ 658.090253] sd 0:0:0:1: [sdb] Very big device. Trying to use READ >> CAPACITY(16). >> [ 658.291130] sd 0:0:0:2: [sdc] Very big device. Trying to use READ >> CAPACITY(16). >> [ 658.524039] sd 0:0:0:3: [sdd] Very big device. Trying to use READ >> CAPACITY(16). >> [ 658.840440] sd 0:0:0:4: [sde] Very big device. Trying to use READ >> CAPACITY(16). >> >> smartd details (before I had the ver 6.5 of 2016) >> >> menion@Menionubuntu:/lib/firmware/brcm$ smartd --version >> smartd 6.7 (build date Mar 8 2018) >> [x86_64-linux-4.15.5-041505-generic] (local build) >> Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org >> >> smartd comes with ABSOLUTELY NO WARRANTY. This is free >> software, and you are welcome to redistribute it under >> the terms of the GNU General Public License; either >> version 2, or (at your option) any later version. >> See http://www.gnu.org for further details. >> >> smartmontools release 6.7 dated 2017-11-05 at 15:20:58 UTC >> smartmontools SVN rev is unknown >> smartmontools build host: x86_64-pc-linux-gnu >> smartmontools build with: C++98, GCC 5.4.0 20160609 >> smartmontools configure arguments: '--prefix=/usr' >> '--build=x86_64-linux-gnu' '--host=x86_64-linux-gnu' >> '--sysconfdir=/etc' '--mandir=/usr/share/man' >> '--with-initscriptdir=no' '--docdir=/usr/share/doc/smartmontools' >> '--with-savestates=/var/lib/smartmontools/smartd.' >> '--with-attributelog=/var/lib/smartmontools/attrlog.' >> '--with-exampledir=/usr/share/doc/smartmontools/examples/' >> '--with-drivedbdir=/var/lib/smartmontools/drivedb' >> '--with-systemdsystemunitdir=/lib/systemd/system' >> '--with-smartdscriptdir=/usr/share/smartmontools' >> '--with-smartdplugindir=/etc/smartmontools/smartd_warning.d' >> '--with-systemdenvfile=/etc/default/smartmontools' '--with-selinux' >> 'build_alias=x86_64-linux-gnu' 'host_alias=x86_64-linux-gnu' >> 'CXXFLAGS=-g -O2 -fPIC -fstack-protector-strong -Wformat >> -Werror=format-security -fsigned-char -Wall -O2' >> 'LDFLAGS=-Wl,-Bsymbolic-functions -fPIC -Wl,-z,relro -Wl,-z,now' >> 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' 'CFLAGS=-g -O2 -fPIC >> -fstack-protector-strong -Wformat -Werror=format-security >> -fsigned-char -Wall -O2' >> >> to make sure that I picked and compiled the correct code I have >> checked the new set_rcap16_first method and it is here: >> >> menion@Menionubuntu:~/smartmontools$ cat scsicmds.cpp |grep set_rcap >> device->set_rcap16_first(); >> menion@Menionubuntu:~/smartmontools$ >> >> I have dome doubts about your code: >> >> if (avoid_rcap16) { >> res = scsiReadCapacity10(device, &last_lba, &lb_size); >> if (res) { >> if (scsi_debugmode) >> pout("%s: READ CAPACITY(10) failed, res=%d\n", __func__, res); >> try_16 = true; >> } else { /* rcap10 succeeded */ >> if (0xffffffff == last_lba) { >> /* so number of blocks needs > 32 bits to represent */ >> try_16 = true; >> device->set_rcap16_first(); >> } else { >> ret_val = last_lba + 1; >> if (srrp) { >> memset(srrp, 0, sizeof(*srrp)); >> srrp->num_lblocks = ret_val; >> srrp->lb_size = lb_size; >> } >> } >> } >> } >> >> from the scsi kernel code I see that also read_capacity_10 return >> capacity in 64bit variable >> >> sector_size = read_capacity_10(sdkp, sdp, buffer); >> if (sector_size == -EOVERFLOW) >> goto got_data; >> if (sector_size < 0) >> return; >> if ((sizeof(sdkp->capacity) > 4) && >> (sdkp->capacity > 0xffffffffULL)) { >> >> so is this if statement correct? >> >> } else { /* rcap10 succeeded */ >> if (0xffffffff == last_lba) { >> >> I means, the last_lba is read from the responde of read_capacity_10 in >> scsiReadCapacity10 via this conversion: >> >> if (last_lbap) >> *last_lbap = get_unaligned_be32(resp + 0); >> >> so are you sure that if the device return more than about 4TB the >> value of this variable will be 0xFFFFFFFFUL? >> Yes, I can make some test myself but today I have so little time to >> experiment, so I have reported it to you I am sure that you will sort >> out quickly if this is the problem or not >> Bye >> >> >> 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) >>> >>> >>> 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? >>>> >>>
