badblocks seems drunk - Page 1
Forum section: electronics / general

author: legacy
author_rank: Super Contributor
timestamp: April 23, 2019, 10:48:36 pm
content: Code:NAMEbadblocks - search a device for bad blocksSYNOPSISbadblocks [ -svwnf ] [ -b block-size ] [ -c blocks_at_once ] [ -emax_bad_blocks ] [ -d read_delay_factor ] [ -i input_file ] [ -o output_file] [ -p num_passes ] [ -t test_pattern ] device [ last-block ] [ first-block ]DESCRIPTIONbadblocks is used to search for bad blocks on a device (usually a disk parti-tion). device is the special file corresponding to the device (e.g/dev/hdc1). last-block is the last block to be checked; if it is not speci-fied, the last block on the device is used as a default. first-block is anoptional parameter specifying the starting block number for the test, whichallows the testing to start in the middle of the disk. If it is not speci-fied the first block on the disk is used as a default.Important note: If the output of badblocks is going to be fed to the e2fsckor mke2fs programs, it is important that the block size is properly speci-fied, since the block numbers which are generated are very dependent on theblock size in use by the filesystem. For this reason, it is strongly recom-mended that users not run badblocks directly, but rather use the -c option ofthe e2fsck and mke2fs programs.Code:badblocks -nv /dev/sdd1 -p1Checking for bad blocks in non-destructive read-write modeFrom block 0 to 62500850Testing with random pattern:350549Code:badblocks -nv /dev/sdd1 -p1Checking for bad blocks in non-destructive read-write modeFrom block 0 to 62500850Testing with random pattern:1210491168665wtf?!?why does it say that block #350549 is a bad-block in the first try, but it doesn't mention it in the second try, reporting blocks #121049 and #1168665 as bad-blocks?this is confusing: the harddrive I am testing is a common electro-mechanical 2.5 inc sATA unit, removed from a laptop. So it's not flash, and it doesn't explain the weird behavior I am observing with the tool badblocksbesides, even more unusual and surprising in a way that is hard to understand, four hours ago, I obtained this:Code:badblocks -nv /dev/sdd1 -p1Checking for bad blocks in non-destructive read-write modeFrom block 0 to 62500850Testing with random pattern:10152052062821311043741580495205665625328173008978348509939612510443737114913491253896513586577146341931568181316729429177770411882465320919881219674972222943724062729251103492615796527205581282531932930080929562749313960413165798133491273345388893480082935586497358484333689604937943665389912814003889341086505421341214318173344229345452769614632457347372177484198014946741750515033515626495261026153657873547054895575310156800713578483295889594559157885602055016125310162300725Pass completed, 61 bad blocks found.It said 61 bad blocksit seems random-something, is it drunk?

author: legacy
author_rank: Super Contributor
timestamp: April 23, 2019, 10:57:00 pm
content: just in case someone is wondering: no, neither the partition under test, nor anything else related to this hard drive is mounted, so badblocks is free and happy to do its tasks without any external influence.

author: amyk
author_rank: Super Contributor
timestamp: April 24, 2019, 12:21:42 am
content: HDDs do silently attempt to remap/recover unusable sectors. What you're seeing is indicative of that behaviour.What are the SMART stats on that drive? In particular, the number of reallocated sectors should be checked, and if it is increasing visibly after each run of that utility (which I presume simply reads sectors consecutively), the drive is going to be dead very very very soon --- in any case, back up everything on that drive ASAP.

author: hamster_nz
author_rank: Super Contributor
timestamp: April 24, 2019, 02:40:08 am
content: The whole "badblocks" thing is an anachronism from ages past, where HDDs were stupid and you had to key in the list of bad blocks that were printed on the drive label. - see attached image.Disks are smarter than most people expect. They try to keep working as much as possible. If they get a read error they will retry quite a few times, and if the ECC checks out they will give you data and carry on like nothing happened, and might even remap to a spare block kept for this purpose.(Well, actually the spare blocks are there so HDD manufacturers don't have to make 100% perfect drives - the drive can ship with quite a few known-bad blocks)Things go really turn to custard when the drive runs out of spare blocks for remapping.The best place to find out what is going on is the S.M.A.R.T. information for the drive. It will tell you exactly what errors are happening, when it happened and hopefully why it happened:https://www.linuxtechi.com/smartctl-monitoring-analysis-tool-hard-drive/

author: ejeffrey
author_rank: Super Contributor
timestamp: April 24, 2019, 04:31:27 am
content: Yeah bad blocks doesn't do much useful any more due to sector remapping. A drive with persistent IO errors is basically dying anyway. That appears to be what is happening here

author: mfro
author_rank: Regular Contributor
timestamp: April 24, 2019, 05:11:26 am
content: Quote from: ejeffrey on April 24, 2019, 04:31:27 amIt's not completely useless.Harddrives do sector remapping on failed write attempts only, i.e. if you have a faulty sector on read, there will be no replacement. So, with a few runs, you might manage to get a failing drive back to a somewhat usable state again. I would not recommend to use such a drive for something important as I would expect it to fail completely anytime soon, however.

author: ogden
author_rank: Super Contributor
timestamp: April 24, 2019, 05:24:39 am
content: Quote from: hamster_nz on April 24, 2019, 02:40:08 amRight. Cause can be interface errors due to inferior SATA cable. When you are getting strange HDD errors - always check against cable problems as well.

author: Berni
author_rank: Super Contributor
timestamp: April 24, 2019, 06:27:26 am
content: Yeah modern hardrives remap bad sectors when they see them.But the fact that new bad sectors pop up on every run of it is good reason to be worried. The drive might have run out of spare sectors to swap in, or some part of its reading or writing process is going wonky.And yes first try using a different SATA cable and plug it into a different port on the motherboard. I bought some shitty Akasa brand SATA cables for my NAS build and was pulling my hair out for a month why i was occasionally getting errors while other times it would work fine.

author: hamster_nz
author_rank: Super Contributor
timestamp: April 24, 2019, 10:14:04 am
content: Quote from: mfro on April 24, 2019, 05:11:26 amHow does the hard disk drive (not badblocks) know it has a failed write attempt, (aside from not finding the sector's header when it is looking for where it starts)? Does each block get read back after it is written and verify that the data can be read?

author: hamster_nz
author_rank: Super Contributor
timestamp: April 24, 2019, 10:56:47 am
content: Long tale cut short, pathologically bad disks sometimes happen.When I was a Customer Engineer for HP, we had a large K-class server (think two and a half racks of server+storage) running Oracle that occasionally reported memory corruption and would core-dump the production databases when heavily loaded causing a nationwide outage.The server's memory ECC logs were clean - these boxes scrub memory when idle, and no memory corruption was seen. Vendor support cases were raised, outages arranged, diagnostics were run, and cases were escalated to highest levels in both HP and Oracle and no cause was found.After a few months of ongoing problems it was replaced with a V-class (a server weighing about 220 kg, with a multi-million $ price tag, and a very deep discount), and the old K-class was re-purposed as test/dev box.After the K-class was reinstalled, the customer started getting file system errors - and not memory errors . I wrote data to each of the disks and checksummed it, and found out that a single Enterprise class SCSI disk was writing OK, then would silently corrupt the data on read.Looking back through records I identified that disk had been configured as a swap device when it was in production. So when heavily loaded it would swap some of the database's data to swap, and a while later a corrupted copy would be swapped back in, crashing the database...We sent it away for failure analysis, and the result came back that part of data path in the SCSI interface didn't have parity, CRC or ECC, and was flaky.

author: hamster_nz
author_rank: Super Contributor
timestamp: April 24, 2019, 11:37:05 am
content: Quote from: legacy on April 24, 2019, 11:01:19 amOpps.As well as working with HP-UX systems, I've had the pleasure of using IBM P-series & I-series systems.Using the IBM diagnostics you can reformat the same disk between the 528 bytes per sector to make pdisks and 512 bytes per sector for hdisks. The extra bytes in the longer sectors are used to make additional data tagging and CRC info visible to the RAID controller.Lord knows how P-series systems get on with SSDs... Oh, it seems they have SSDs with 528 byte sectors, that you can't use diags to reformat to 512 byte sectors, so you can't boot an OS directly from them without first using diags to make a RAID array. How nice - typical IBM.

author: drescherjm
author_rank: Contributor
timestamp: April 24, 2019, 01:06:02 pm
content: QuoteSeems pretty slow for a modern drive. I assume this is a 5400 RPM or slower.QuoteThat should tell us a lot.Reallocated_Sector_Ct, Current_Pending_Sector, Offline_Uncorrectable, UDMA_CRC_Error_Count, UDMA_CRC_Error_Count, and Power_On_Hours are usually very helpful at diagnosing problems:I wrote a script years ago that I use on my disks (at home and work I have several hundred drives)https://raw.githubusercontent.com/drescherjm/jmdgentoooverlay/master/Other/shell-scripts/examine_smart.sh

author: drescherjm
author_rank: Contributor
timestamp: April 24, 2019, 03:22:55 pm
content: QuoteWhy I mentioned that is the performance is so bad that this could be an additional indicator to drive failure.

author: Berni
author_rank: Super Contributor
timestamp: April 24, 2019, 03:36:48 pm
content: Yeah indeed drops in speed or inconsistent performance are a common sign of slowly failing drives. But its normal for low RPM laptop drives to be pretty slow in general, even modern ones. But yeah SMART will tell you the most about a drives health.Since you are using Linux by the looks of it, i guess you can also format it into ZFS to help protect it from corruption if you really want to keep using it.

author: magic
author_rank: Super Contributor
timestamp: April 24, 2019, 04:20:19 pm
content: Consumer disks don't do write-read-verify. I believe it only happens if the disks writes to a sector that was previously known as corrupted and only then, if verification fails, the disk may consider permanently remapping the sector.It appears that data corruption can also happen due to transient faults and writing new data to the same sector clears the problem. I have seen several disks which reported read errors and re-writing them made "pending sector count" go to zero without increasing "reallocated sector count".Of course a disk which writes corrupt sectors every now and then is likely to keep doing so in the future and keep getting worse.

author: legacy
author_rank: Super Contributor
timestamp: April 24, 2019, 04:41:50 pm
content: Code:sdd User Capacity: 160,041,885,696 bytes [160 GB] Serial Number: 5VCHZ1AJ5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 09 Power_On_Hours 0x0032 085 085 000 Old_age Always - 14005188 Command_Timeout 0x0032 100 099 000 Old_age Always - 8590065668195 Hardware_ECC_Recovered 0x001a 059 053 000 Old_age Always - 81578831197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0this is what smartctl says

author: drescherjm
author_rank: Contributor
timestamp: April 24, 2019, 07:06:06 pm
content: Your SMART status looks fine to me except for possibly Hardware_ECC_Recovered but that is not always consistent between manufacturers.

author: legacy
author_rank: Super Contributor
timestamp: April 24, 2019, 07:51:29 pm
content: yes, the report looks "fine", so it looks really weird to me: I expected something bad reported, and there is no clue.May be problems are the on the electronic, on the back of the hard drive, or on the cable but the cable is brand new, tested several cables, and all made the same results.May be the problem is a firmware incompatibility with the SATA controller, but I tested a couple of controllers by different bands, and all made the same results.Now I am stressing the hard drive with "badblocks" in destructive mode and running in loop. it's a long-time running task and I will check tomorrow morning.

author: drescherjm
author_rank: Contributor
timestamp: April 24, 2019, 07:58:35 pm
content: Cable problems usually show up in UDMA_CRC_Error_Count.QuoteI know. I have done this 100s of times. Even with 8+TB drives (that take 4+ days for the 4 pass destructive mode).

author: 2N3055
author_rank: Super Contributor
timestamp: April 24, 2019, 08:13:52 pm
content: One of the failure modes for classic HDD is that they develop problems with head positioning. It can be tolerance in head bearings, or something else.. It starts to develop unstable seeking. Servo algorithms do position it eventually over the cylinder well enough for ECC to do it's job. You will notice it as drive that slows down a bit, and as it progresses, it will start to be audible when head is struggling. But at the beginning you won't hear much.It will throw occasional ECC error or bad sector.Bottom line that drive is dead. Backup data ASAP and smash it with a hammer.Today drives have built in relocation clusters space reserved. It happens completely in background, and if your OS reports bad sectors that means drive is DEAD. It means that drive used up all reallocation space, so like 5-10% of your drive is already dead.And manufacturers are NOT reporting that stuff in SMART most of the time..

author: magic
author_rank: Super Contributor
timestamp: April 25, 2019, 10:01:19 pm
content: Quote from: legacy on April 24, 2019, 04:41:50 pmThis looks like a good disk. Is the error log empty (printed by smartctl -a)?Frankly, I see no mention of the OS reporting bad sectors here, just some problems with badblock. Any errors in dmesg?Alternatively, badblock failure could possibly be caused by data corruption. Bad RAM, crappy USB SATA bridge, etc.

author: amyk
author_rank: Super Contributor
timestamp: April 26, 2019, 12:08:19 am
content: Quote from: 2N3055 on April 24, 2019, 08:13:52 pmThis is why I recommend doing a scan with a program like MHDD, which is sensitive enough to identify "weak sectors". (It's sensitive enough that ambient vibration and even softly touching the drive while it's being scanned will be visible, so don't do that...)

author: legacy
author_rank: Super Contributor
timestamp: April 26, 2019, 09:54:03 am
content: Quote from: magic on April 25, 2019, 10:01:19 pmnothingQuote from: magic on April 25, 2019, 10:01:19 pmRAM check: all okSATA controller diagnostic: all okand it happens ONLY with that goddamn harddriveI have two Hitachi harddrives, I tried both on the same machine with the same configuration, with the same badblocks' flags: all okso WTF, really

author: ogden
author_rank: Super Contributor
timestamp: April 26, 2019, 10:56:35 am
content: Reason of errors could be supply ripple that is caused by faulty capacitor(s). Supply noise can leak into HDD read amplifier and errors depend not on actual HDD data recording but power consumption pattern of HDD. List of non-obvious reasons of intermittent errors can be quite long. You can't trust that HDD anymore anyway. Let it go

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: April 26, 2019, 11:21:07 am
content: If it's a fujitsu just throw it in the trash.

author: magic
author_rank: Super Contributor
timestamp: April 26, 2019, 04:29:43 pm
content: Quote from: legacy on April 26, 2019, 09:54:03 amSo it's not bad sectors and not cable noise. Those are ECC/CRC protected and errors are reported.Supposedly there is some remote chance of corruption in the HDD controller chip or its cache, though I would hope such problems wouldn't go unreported. SMART "short" self-test may try to detect faults in HDD cache RAM.Other than that, I would say it must be software issue of one sort or another or a crappy USB/SATA bridge if you use one. I have seen those things silently corrupt data.

author: legacy
author_rank: Super Contributor
timestamp: April 26, 2019, 04:49:19 pm
content: So in the last 24 hours the hard-drive was tested in a continuous bad block loop test, reporting random failures only in badblocks but not in the kernel dmesg, and all of this went ahead until it suddenly stopped. I rebooted the machine and now it's no more seen on the SATA chain, the disk-probe of SATA controller does no more see it, like if it was a piece of dead electronic.is it really dead? I unmounted the hard-drive and checked it on my laptop: yes, it's gone, no responseLesson learned: even if errors were reported neither by SMART nor by dmesg, the first symptom of malfunction reported by badblocks was a sign that the reaper was coming.Rest In Peace.The only irritating things is that by checking the backup integrity, big files are all corrupted. I have a sane backup, but it's synchronized to one week ago. It's better than nothing.

author: legacy
author_rank: Super Contributor
timestamp: April 26, 2019, 04:51:10 pm
content: Quote from: GeorgeOfTheJungle on April 26, 2019, 11:21:07 amIt *was* a Seagate.

author: legacy
author_rank: Super Contributor
timestamp: April 26, 2019, 05:26:08 pm
content: before trying badblocks, yesterday I formatted the harddrive and did a couple of testsCode:# lssize data1.bin400 Mbyte# cp data1 data2md5sum data1.bin data2.bin6004eb9dd9189770655f8b49a1d688a8 data1.bin6004eb9dd9189770655f8b49a1d688a8 data2.binCode:# lssize bigone15 Gbyte# cp bigone1 bigone2# md5sum bigone*f60a9f7ff4bcec465ea47e0f009354fd bigone15e1fdedc560cfe82a5d59b740a980091 bigone2There was no error reported by "cp", and dmesg didn't report anything wrong, but look at the md5sum of the last one: it's clearly a good indication that the copy is corruptedso copying files from A to B is now making me anxious because the above is terrifying

author: ejeffrey
author_rank: Super Contributor
timestamp: April 26, 2019, 05:28:46 pm
content: I agree this could actually be bad memory or an overclocked/undercooled CPU. That would explain the clean SMART response and the lack of kernel IO error messages.

author: legacy
author_rank: Super Contributor
timestamp: April 26, 2019, 05:44:48 pm
content: Quote from: ejeffrey on April 26, 2019, 05:28:46 pmNo, it was a defective hard-drive. Everything else works as expected. The point is how to prevent this from happening in the future, because this experience has shown that you can trust neither SMART nor dmesg when the electronic on an hard-disk is going to die.

author: ogden
author_rank: Super Contributor
timestamp: April 26, 2019, 05:50:51 pm
content: Quote from: ejeffrey on April 26, 2019, 05:28:46 pmRight. Next thing to do - memory (burn) tests.

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: April 26, 2019, 05:54:16 pm
content: The fujitsus always report as ok in SMART even when the platter is totally gone...

author: ebastler
author_rank: Super Contributor
timestamp: April 27, 2019, 06:36:53 am
content: Quote from: legacy on April 26, 2019, 04:49:19 pmHmm, hard to say whether those sporadic badblocks were related to the issue which eventually killed the drive. Maybe the drive died from a heart attack due to the intense 24h continuous testing -- that might well have been more action than it ever saw in its lifetime... (Do disk drives come in different robustness classes, or are they all specified to withstand round-the-clock action?)If a used drive is meant to go into server duty, an intense test which simulates those conditions makes a lot of sense. On the other hand, when building a vintage system for light desktop duty, I'm not sure whether I would put that much stress on the components during testing.EDIT: Seems that typical SATA drives are specified for 8 hours/day, 5 days/week operation only. I am not sure whether that is just the basis for calculating the total number of operating hours over their XX year lifetime, or whether the thermal design assumes cooling-off periods? It might be possible to "test a drive to death" then, by operating it outside of its spec.

author: hamster_nz
author_rank: Super Contributor
timestamp: April 27, 2019, 08:02:02 am
content: Wow... That is the second time I've seen your issue.It just doubled my resolve never to trust a single individual part of computer (or cloud service) with important stuff. Always have a backup plan!The hard part now is that you can't tell which services are now built on the same cloud infrastructure..

author: magic
author_rank: Super Contributor
timestamp: April 27, 2019, 09:52:36 am
content: Time to pull out a scope and DMM and check all voltage rails on the disk. If you are lucky, it's just a shitty capacitor somewhere.Quote from: ebastler on April 27, 2019, 06:36:53 amDisks have no heart and no reason to fail from a 24h burst of activity, unless it overheats or is already about to kick the bucket.

author: Rerouter
author_rank: Super Contributor
timestamp: April 27, 2019, 12:49:29 pm
content: A cross check can be HDtune free version, ticking "verify" in the erase patterns, e.g. Random or DoD, It will sweep the drive a few times, and if it gets any mismatches will throw an error. Its how I vet most of my new drives when I get them by running 4-7 passes of the DoD pattern, and make sure no pending or reallocations happen,Pitty the MHDD tool is boot disk only, would love to know if there is a windows equivalent that looks at how long it takes to respond to requests over the disk to identify weak sectors. (in about a months time have about 80TB of drives to run health checks on before building into a new array)

author: Rerouter
author_rank: Super Contributor
timestamp: April 27, 2019, 12:56:26 pm
content: As per the dead drive, My suspicion is a blown protection diode on a different rail to the one you where powering, generally you will need to power both the 5V and 12V rails to get a drive to spin up,If its a 7200.11 / 7200.12 seagate, they had firmware bugs in some models for a while, and had a hard to find updater tool to patch the new firmware, otherwise they could brick them self. If i recall the unofficial option then was that the diagnostic pins next to the sata data cable plug was a serial command line interface of sorts that you could use to flash in or out the firmware.As per drive robustness, part of it comes down to how much there vibration is dampened, How many times the drive powers up from off, and how many times it parks its heads, these all contribute to mechanical failures, as to the software and cache corruption, that generally comes down to airflow / temperature, Ideally you don't want hard drives running hotter than 45C for high reliability,Most of the drive option you see today are a mixture of how vibration tolerant the drive is, with other settings like how long it will attempt to recover a hard to read bit of data from a NAS focused drive, with linux most of the settings of the drive can be tweaked by the user, but it has to be set every time the machine reboots.The warrenty period most of the time gives an indication to how long they hope the drives to last for, but if you treat them well, let them spin and keep them cool, you can have very long lasting drives once you get past infant mortality. various data providers have released solid numbers on what model hard drives tend to die the most, with some being as high as 5% the first year, with most tapering off significantly after that time.

author: ebastler
author_rank: Super Contributor
timestamp: April 27, 2019, 01:15:01 pm
content: Quote from: magic on April 27, 2019, 09:52:36 amOh really?!OK, I'll use more smileys going forward.QuoteWell, that's the question I was asking. Are consumer HDDs, especially the 2.5" notebook ones, specified to sustain 24/7 operation with permanent activity? Specifically, is their heat management designed to cope with that?

author: Gyro
author_rank: Super Contributor
timestamp: April 27, 2019, 01:57:04 pm
content: Quote from: ebastler on April 27, 2019, 01:15:01 pmIt's hard to know these days, it certainlyusedto be the case that 3.5" were more reliable in constant operation but I'm not sure if the balance has reached tipping point yet. You could argue that much lower power consumption, lower inertia of the head assembly, smaller platters meaning less possibility of large out of balance mass causing less structural vibrations, less turbulence etc. are all in the favour of 2.5".I suspect that the manufacturers attempt to achieve similar aerial density, regardless of platter size, in order to maximize capacity for the lowest number of platters.2.5" are certainly quieter, that must mean something in mechanical terms.

author: legacy
author_rank: Super Contributor
timestamp: April 27, 2019, 02:43:02 pm
content: Quote from: Rerouter on April 27, 2019, 12:56:26 pm3.5" typically require 12v and 5v, most 2.5" drives only use the 5v supply. That Seagate one seems to use only 5V.

author: legacy
author_rank: Super Contributor
timestamp: April 27, 2019, 02:45:29 pm
content: Quote from: Rerouter on April 27, 2019, 12:56:26 pmdamn, we have a few of them in our stock: 7200.11(never used, still in the box .. now I understand WHY on Amazon they were offered with -50%)

author: magic
author_rank: Super Contributor
timestamp: April 27, 2019, 03:49:41 pm
content: Quote from: ebastler on April 27, 2019, 01:15:01 pmConsumer HDDs aren't really specified for anything, I just checked the datasheet of one of mine and it only specifies expected read error rate per petabyte and annual failure rate, not even sure how "failure" is defined in the latter case.At the same time, there isn't much I/O you can do over 24h and no disk should care whether that amount of I/O happens all at once or over 5 years (save for power dissipation concerns) and no disk is specified to fail that amount of I/O because disks would be failing left and right if it were so.They also give 2 years or so of warranty and I haven't yet heard of manufacturers refusing warranty for too much I/O. Endurance specs are common on SSDs where there is a clear limit on the number of write cycles the flash can take, not so much on spinning rust. Many disks don't even seem to count total I/O over lifetime, although some do and report it via SMART.

author: ebastler
author_rank: Super Contributor
timestamp: April 27, 2019, 04:23:13 pm
content: Quote from: magic on April 27, 2019, 03:49:41 pmI was not thinking of a "total number of I/O bytes" limit, but was rather wondering about electronics or mechanical bearings overheating during prolonged, intense operation.But indeed, most HDD manufacturers don't seem to specify any limitation. Western Digital does (did?) for their Travelstar:https://documents.westerndigital.com/content/dam/doc-library/en_us/assets/public/western-digital/product/hgst/travelstar-5k-series/product-manual-travelstar-5k750-standard-models.pdfQuote

author: amyk
author_rank: Super Contributor
timestamp: April 27, 2019, 07:11:37 pm
content: No surprise, it's a Seagate...Quote from: Rerouter on April 27, 2019, 12:49:29 pmWindows itself can't provide such tight timing guarantees consistently, because it's a multiprocessing OS. Only pure MS-DOS with nothing else running on the machine can be quiet enough to see the difference.

author: Rerouter
author_rank: Super Contributor
timestamp: April 27, 2019, 09:10:39 pm
content: found the guide for the 7200.11'shttps://www.webfoobar.com/index.php/node/6At a minimum is spits out what the current error is generally over that interfaceand the firmware updater toolshttps://www.seagate.com/au/en/support/kb/firmware-update-for-st3500320as-st3500620as-st3500820as-st3640330as-st3640530as-st3750330as-st3750630as-st31000340as-207951en/https://www.seagate.com/au/en/support/kb/barracuda-720012-firmware-update-213891en/

author: magic
author_rank: Super Contributor
timestamp: April 27, 2019, 09:21:22 pm
content: Quote from: ebastler on April 27, 2019, 04:23:13 pmI don't think it's an issue. Mechanical parts are mounted to a solid aluminum frame for rigidity, which provides heatsinking too. In good airflow a 100% busy disk reaches thermal equilibrium pretty fast and its temperature (as reported by SMART) doesn't climb up for hours. Things may be different in some crappy enclosure or a laptop.I sometimes tested disks for hours or overwrote them completely with zeros and never managed to kill any. I maintain that OP's disk must have already had some problem with the controller.QuoteWell, so I suppose it's within intended usage conditions to load it once per month for 66 hours straight as long as it is followed by 266h of idle spinning and another 300h of restAs an aside, 20% spent in I/O is actually quite a lot and a good spec for anything but a busy server. I am absolutely certain that no of my desktop/laptop disks ever came even close.

author: hamster_nz
author_rank: Super Contributor
timestamp: April 27, 2019, 10:26:03 pm
content: Quote from: amyk on April 27, 2019, 07:11:37 pmThere are plenty more layers of abstraction below the OS that needs to be broken through for this to work anything but in a haphazard way.'weak sectors' is just a euphemism for 'unknown, repeatable, recoverable error'. Plenty of different causes that all look the same higher up in the stack.The SMART stats is the correct place for this to be logged and reported. Shame it is so poorly supported on consumer-level disks.

author: magic
author_rank: Super Contributor
timestamp: April 28, 2019, 09:03:50 am
content: Quote from: legacy on April 26, 2019, 04:49:19 pmNever too late to learn not to take irreversible actions when dealing with unexpected behaviorQuote from: legacy on April 26, 2019, 06:20:16 pmBetter unmount and power cycle the storage device. There is plenty of caches which may return correct data despite garbage has been forwarded down the line.It won't save you from a device which only sometimes corrupts data and only on readout. I store md5sums alongside files that I care about preserving accurately.The good news is that at least data on platters is ECC protected. There is virtually no possibility of undetectable corruption there - if it reads correct today, it will read correct tomorrow or it will not read at all. And corruption in any other place can be resolved by re-reading. If you detect it.

author: hamster_nz
author_rank: Super Contributor
timestamp: April 28, 2019, 09:21:29 am
content: Quote from: magic on April 28, 2019, 09:03:50 amIf it gives the same corrupted hash on multiple reads it was corrupted before the write and all hope is lost.If the hash changes, then you can try to copy the file multiple times (making sure you power cycle to clear the cache) and then write a small bit of code to see which bytes in the copies agree, and ignore the odd ones out.Such a technique can even work with entire file systems if you have enough disk space.But in this case it sounds like the problem disk has died.

author: MarkL
author_rank: Unknown
timestamp: April 28, 2019, 07:23:04 pm
content: Quote from: legacy on April 28, 2019, 01:00:14 pmYou might want to take a look at rsync which verifies each completed transfer with a checksum (this is a separate checksum from figuring out which files need to be transferred).Since you want to verify the actual data written to the physical disk, beware of data sitting around in caches, especially if the read is shortly after the write. There's lots of opinions on how to flush/invalidate all the caches. Here's one post that seems fairly complete:https://stackoverflow.com/questions/9551838/how-to-purge-disk-i-o-caches-on-linux

author: hamster_nz
author_rank: Super Contributor
timestamp: April 28, 2019, 09:16:49 pm
content: Quote from: MarkL on April 28, 2019, 07:23:04 pmRsync may not be the tool you are looking for. Rsync's focus it to minimize network traffic during a network copy.I guess you could copy an unchanging file multiple times to the same destination twice, and if it transfers data on the the second copy then you know something is broken.However, you were already doing that with 'cp' and 'md5sum', and you know things were broken...