Ontopic Random Computer-Electronics Thread

the dude that keeps propogating it (ZFS dev by the way) does not understand URE behavior on modern hard disks.

His claim is that during a raid rebuild, you're guaranteed to have a URE (unrecoverable READ error), which will then break the rebuild. But that aint how URE's work on modern hard drives. The unrecoverable in URE means that the standard read attempt timeout has occurred. usually 3 tries. Modern HD firmwares have provisions to account for UREs and allow flexibility when the try limit is exceeded rather than just slamming the disk head down and saying "fuck you drive is dead" like they used to
The math works out in his favor, and it's a published paper in the ACM. I'm going to take papers from the ACM and my own experience working in the storage field over some rando who homelabs' 5 minutes of google any day of the week.
 
The math works out in his favor, and it's a published paper in the ACM. I'm going to take papers from the ACM and my own experience working in the storage field over some rando who homelabs' 5 minutes of google any day of the week.

The math is fine, his data is bad. He also doesnt account for sector ECC which can handle a URE within a sector.
 
I did data recovery professionally back when drive firmwares were way shittier than they are now, and even then, the precautions in place were better than his assumptions that a URE truly causes a serious problem.
 
I did data recovery professionally back when drive firmwares were way shittier than they are now, and even then, the precautions in place were better than his assumptions that a URE truly causes a serious problem.
I'm currently writing emulation code to simulate hardware failures in a controlled environment, and I assure you that UREs do cause a serious problem.
 
I'm currently writing emulation code to simulate hardware failures in a controlled environment, and I assure you that UREs do cause a serious problem.
Tell me how your emulation addresses sector ECC please? Specifically 100 byte 4k sector size ECC.
 
Tell me how your emulation addresses sector ECC please? Specifically 100 byte 4k sector size ECC.
Generally, we load the firmware of the drive type to be emulated.

1-bit errors occur fairly frequently (and are correctable), but some drives are more immune than others, depending on how much wasted write they do (vs. padding or leaving uninitialized).

Spindle hard disks are unreliable, and they've had a lot of firmware development to kinda sorta make them work, but it really just depends on how much or little you value the data you put on them.
 
Thats a good technique. It also depends on the precision of your data.

Calculating PI to a billion places? every bit matters.

Storing a bunch of images? You can probably flip 10% of the bits before you even notice it.
 
Thats a good technique. It also depends on the precision of your data.

Calculating PI to a billion places? every bit matters.

Storing a bunch of images? You can probably flip 10% of the bits before you even notice it.
Yeah, but I'm concerned with being able to successfully rebuild an array.

Let's look at the use case: you've bought a bunch of the same drive, and one's gone tits-up. That means that the drive you're replacing has already silently corrected as many UREs as it can, and likely the other drives in the array are near the same state.
 
  • Gravy
Reactions: Domon
Yes please.

I've got the bits for a nice little mini server. :cool:

You want me to ship em to ya, or meet up sometime? I've been curious to check out community forklift, so i might swing vaguely in your direction sometime. I work in west laurel now, so im a bit closer from work than home over by annapolis
 
You want me to ship em to ya, or meet up sometime? I've been curious to check out community forklift, so i might swing vaguely in your direction sometime. I work in west laurel now, so im a bit closer from work than home over by annapolis

I'd definitely be interested in checking out Community Forklift.

Bet I could get into some trouble out there :fly: