From: robin_listas@es.invalid   
      
   On 2025-05-18 21:40, Paul wrote:   
   > On Sun, 5/18/2025 12:44 PM, Carlos E. R. wrote:   
   > ) Unconditional use. Transfer curve is relatively smooth.   
   >>   
   >> I had not seen this idea of a transfer curve before. Interesting.   
   >   
   >> As long as the computer was not busy those instants. The test can take many   
   hours to run.   
   >>   
   >   
   > The benchmarks take tiny samples. The setting for the picture was   
   > "1000 samples of 10MB each". That means a kind of crude statistical   
   > sample. if you play with the settings, you might notice the interaction   
   > between those settings choices, and the amount of "artifacts" in the   
   > trace.   
   >   
   > I'm only reading a small fraction of the drive surface. I'm taking   
   > a thousand samples. I hope I hit the track that has the huge   
   > number of reallocations on it, to get a representative sample.   
   >   
   > I *have* set up a disk before, to bench the whole thing, inch by inch,   
   > from end to end. That took five hours and a "custom technique" not   
   > suited for others.   
   >   
   > Any scheme you offer for "vetting" disks, can't particularly   
   > have a long execution time, as then users won't use it. As long   
   > as the bench runs in a couple minutes, most people can manage that.   
   >   
   > The thing is, we need to teach people of the need to "vet" disks   
   > before it is TOO LATE. I hate listening to someone whine about   
   > their drive full of CRC errors, and their fervent hope all the   
   > data will be rescued by some miracle. I hope that maybe, maybe,   
   > just once, someone will follow the instructions to bench a drive,   
   > and notice it is sick, and get the data off before the disk is ruined.   
   >   
   > It should be noted, that the zone recording scheme of disks,   
   > has "peculiar behavior". An ex-employee at a disk company, was   
   > explaining some of this on his web site (until the company lawyers   
   > detected the leak and shut him down). Some of the disk drives   
   > you buy *cannot* have smooth edges in the graph. The ripple in   
   > the transfer rate, is due to how the tracks are set up, and   
   > the rate on each track can be custom.   
   >   
   > Some drives, just the main zones are visible. Each zone is "flat as   
   > a straight edge" on top. For those drives, excursions in   
   > storage performance show up well. The hard drives (even modern   
   > ones) with "gravel on the edges of the graph", it is then   
   > harder to spot real/mechanical trouble as a result. The drive   
   > looks "slightly flaky" from the first day you use it. (And no,   
   > that is not supposed to be an SMR drive either, it's a PMR   
   > with gravel on the bench graph.)   
   >   
   > If at first, your two minute bench does not look "pretty",   
   > try adjusting the number of samples and the sample width, and   
   > see if that modifies the artifacts from the benching method.   
      
   I do the long SMART test. I know it take hours, so I usually do it   
   during the night, but I can keep using the computer meanwhile.   
      
      
   > When hard drives leave the factory, they already have reallocations   
   > on them. The reason the "Reallocated" SMART parameter is not an   
   > honest, linear, indicator is because customers would "cherry pick"   
   > drives and keep sending hard drives back to Newegg, until   
   > they got a "perfect one". To stop that from happening, the   
   > Reallocated statistic always reads 0 when the drive leaves   
   > the factory. This prevents those "special" customers from using   
   > a precision Reallocated statistic, to cherry pick drives.   
      
   Ah. I suspected this, but no one confirmed. It was this way in the past,   
   disks came with a sticker listing known bad blocks. It doesn't trouble me.   
      
      
      
   > But because the Reallocated statistic is not an honest one,   
   > we cannot "chart" the health of the drive over its lifetime,   
   > and plot "reallocations versus time". It is for this reason,   
   > that I use the read benchmark as a "proxy for surface damage".   
      
   Ah. Interesting.   
      
   > if the disk drive company won't be honest with us, we have to   
   > come up with some sort of solution for an early warning.   
      
   At least Seagate disks come now with a very extended logs. In Linux I   
   obtained them with "smartctl -d sat -l farm /dev/sdX":   
      
   This is the end part of one:   
      
                    Number of Reallocated Sectors by Head 0: 0   
   		Number of Reallocated Sectors by Head 1: 0   
   		Number of Reallocated Sectors by Head 2: 0   
   		Number of Reallocated Sectors by Head 3: 0   
   		Number of Reallocated Sectors by Head 4: 0   
   		Number of Reallocated Sectors by Head 5: 0   
   		Number of Reallocated Sectors by Head 6: 0   
   		Number of Reallocated Sectors by Head 7: 0   
   		Number of Reallocated Sectors by Head 8: 0   
   		Number of Reallocated Sectors by Head 9: 0   
   		Number of Reallocation Candidate Sectors by Head 0: 0   
   		Number of Reallocation Candidate Sectors by Head 1: 0   
   		Number of Reallocation Candidate Sectors by Head 2: 0   
   		Number of Reallocation Candidate Sectors by Head 3: 0   
   		Number of Reallocation Candidate Sectors by Head 4: 0   
   		Number of Reallocation Candidate Sectors by Head 5: 0   
   		Number of Reallocation Candidate Sectors by Head 6: 0   
   		Number of Reallocation Candidate Sectors by Head 7: 0   
   		Number of Reallocation Candidate Sectors by Head 8: 0   
   		Number of Reallocation Candidate Sectors by Head 9: 0   
      
   --   
   Cheers,   
           Carlos E.R.   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)