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? >>> >>
