Runtime filesystem consistency checking

I understand that these days, it's the disk firmware's job to do this. It knows that there's a read error (which Linux doesn't, although it can sometimes guess ¹); it knows that sector is dodgy (which Linux doesn't, because it doesn't get told when the hardware remaps sectors), it can try re-writing the sector, and if that fails, it can remap in a spare sector (which Linux can't do, because it doesn't have access to the disk's spare sectors) if (and only if) it knows what that sector's contents should be, either because it's managed to read something, or the computer is overwriting that sector.

And it can do all of that without having to worry about which operating system is running, or it's a database using raw access, or if it's a light layer using BIOS calls but no filesystem. It can preserve this information across reformats.

In your case, by causing the sector containing the directory entry to be rewritten, the disk probably decided that this was a great time to remap in a spare sector, so it actually went to a different part of the disk. (Unless the filesystem you were using put the new directory entry somewhere else anyway.)

And ECC correction doesn't take seconds; re-reading the same sector repeatedly in the hope that you can get a last good read does.

¹ If you've got command queueing turned on, several requests outstanding, and there's a delay, which sector caused the problem?