On 01/08/2020 07.23, David Haller wrote:
Hello,
On Fri, 31 Jul 2020, Carlos E. R. wrote:
On Friday, 2020-07-31 at 05:26 +0200, David Haller wrote: [..]
Hm. Seems like the kernel changed the sysfs contents (and thus also udev's by-path links? I only have e.g. by-path/pci-0000:00:11.0-scsi-0:0:0:0-part1)...
Ah, yes. This should work:
Let's see:
Telcontar:~ # ataid_to_drive.sh ata3.00 ata3.00 is: [ 2.499081] sd 2:0:0:0: Attached scsi generic sg2 type 0 [ 2.545493] sd 2:0:0:0: [sdc] Attached SCSI disk Telcontar:~ #
Yes, sdc :-)
But it is SATA, not SCSI
But the SCSI subsystem ;)
Anyway, this "manual" mode might work:
$ HOSTID=$(ls -d /sys/bus/pci/devices/*/ata3/host* | sed '@.*/host@@') $ dmesg | grep "\] s[dr] ${HOSTID}:0:0.*Attached"
Let's see.
Hum.
Telcontar:~ # HOSTID=$(ls -d /sys/bus/pci/devices/*/ata3/host* | sed '@.*/host@@') sed: -e expression #1, char 1: unknown command: `@' Telcontar:~ #
I'm not fluent with sed, so I can't see what the error is.
Telcontar:~ # ls -d /sys/bus/pci/devices/*/ata3/host* /sys/bus/pci/devices/0000:03:00.1/ata3/host2 Telcontar:~ #
*grr* There's a 's' gone missing in copy & pasting...
HOSTID=$(ls -d /sys/bus/pci/devices/*/ata3/host* | sed 's@.*/host@@')
Then: Telcontar:~ # dmesg | grep "\] s[dr] ${HOSTID}:0:0.*Attached" [ 2.499081] sd 2:0:0:0: Attached scsi generic sg2 type 0 [ 2.545493] sd 2:0:0:0: [sdc] Attached SCSI disk Telcontar:~ #
^ that bugger
Basically it gets the number(s) at the end of the 'host', e.g. a '2' if you have e.g. /sys/bus/pci/devices/0000:03:00.1/ata3/host2/. And then you grep dmesg for e.g. '] s[dr] 2:0:0.*Attached' which catches the above 2 lines from the script.
Ok!
That's what I looked at (and a bit), but can't say anything about the difference between regular and _EXT flush. I mentioned that just for anyone interested do go digging deeper as a good starting point ;) And yeah, mc is wonderful for digs in the kernel- (and other) sources :))
Ah, so perhaps dig into the sources of snapper. Mmm.
That would be a possibility ;)
[..]
1 Raw_Read_Error_Rate 0x000f 081 062 006 Pre-fail Always - 139054323 7 Seek_Error_Rate 0x000f 088 060 045 Pre-fail Always - 701010635 195 Hardware_ECC_Recovered 0x001a 081 064 000 Old_age Always - 139054323
Now, these would be quite suspicious. Were this not a Seagate drive :) ISTR they come out of the box something like this...
Yes, they have large error rates compared to other brands.
Or rather, the numbers are somewhat random / bogus, but way too high anyway on Seagates.
I have a new disk of that size and brand on another computer (home server):
Same sector size:
Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes
Model Family: Seagate Barracuda 3.5 Device Model: ST4000DM004-2CV104 Firmware Version: 0001 [..] 1 Raw_Read_Error_Rate 0x000f 078 070 006 Pre-fail Always - 56542912 7 Seek_Error_Rate 0x000f 068 060 045 Pre-fail Always - 5720154 195 Hardware_ECC_Recovered 0x001a 078 070 000 Old_age Always - 56542912
same spiel ;)
The "problem" disk is:
Model Family: Seagate BarraCuda 3.5 Device Model: ST4000DM004-2CV104 Firmware Version: 0001
What, same model after some years?
The thing is, this model is listed as being the new SMR type. But it isn't:
Isengard:~ # hdparm -I /dev/sde | grep -i TRIM Isengard:~ #
Didn't I read something of "drive-managed SMR"?
Dunno. Google: Search Results Featured snippet from the web Drive-managed SMR, where the drive manages all write commands from the host, allows a plug-and-play implementation, compatible with any hardware and software. However, the background 'housekeeping' tasks that the drive must perform result in highly unpredictable performance, unfit for enterprise workloads. Making Host Managed SMR Work for You – Dropbox's ... https://blog.westerndigital.com/host-managed-smr-dropbox/ And that's the other thing, the speed is consistent and "fast". On the server, I overwrote it completely, and it did about 130MB/S. For several hours it went at 170 or so. People say that SMR gets down to 40 on large writes, and mine was a hell of a large write. The "server" has a low power cpu (Intel(R) Pentium(R) CPU N3710 @ 1.60GHz), and the hard disks are external via usb3. And the writing was filling the entire disk with almost random data with a concoction of mine that does it fast - all of that might account for lowering the speed when I was not looking.
Anyway, I concur that it's likely a flaky cable. But keep that "cache flush" issue in mind. You might try to trigger it with
How? Ah, below.
(while tailing messages) unmounting all partitions on that disk and then, after reading it all up in 'man hdparm':
# sync # hdparm -f /dev/sdc # hdparm -F /dev/sdc # hdparm -y /dev/sdc maybe: # hdparm -Y /dev/sdc
Ah, this would trigger it?
I think -f/-F send a flush(_ext?), and -y/-Y tells it to shut off also with a flush(_ext?) I guess...
I routinely use 'hdparm -y' to shut down external disks before switching off the power of the case. Might be worth a try to do that while watching dmesg/messages. Unless you cut power, you can wake the disk up again, e.g. by using 'mount', hdparm -I or whatever. ;)
I'll put that in the to-do list :-) Meanwhile, I replaced the 4 sata cables. I think they were a bit forced by the metal cover of the box.
BTW: you might want to configure smartd to not log all temp-changes.
Well, it is noise mostly, I agree, but I did not bother.
Thing is for relevant stuff not to get overlooked in all the noise. Improving the SNR in logfiles is good ;)
That's true.
Something like:
DEFAULT -I 190 -I 194 -I 231 -W 1,40,45
or some such, see 'man 5 smartd.conf'... Not sure if you have to disable the "DEVICESCAN" feature for that.
When I remember, I do disable it, yes. I don't always remember.
Do you add disks so often? I have some "placeholders" for external disks:
This machine doesn't have external sata connectors. My previous machine did. :-( So my temporary external disks are tested manually.
/dev/sdh [regular internal disk] /dev/sdi -d sat -n standby,q -a -I 194 -I 190 -I 231 -I 9 \ -T permissive -d removable /dev/sdj [..same...] /dev/sdk [..same...]
It is simply that I have so many things in my head that I forget to do things. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)