| From: Geoffrey Leach <geoffleach.gl@xxxxxxxxx> | Tip of the hat to whoever created the Fedora Live troubleshooting. It has | (at least) gparted, fdisk, fsck, smartctl and badblocks. Seems like that | should be enough for my purposes. (Aside from a hammer :-) | | Interestingly, the first three do not find any issues. badblocks froze the | system. smartctl is running, so we'll see I'm not sure that there are any use-cases for badblocks(8) on a modern disk. All modern disks want to handle bad blocks themseleves, behind the scenes. When a bad block is detected during a write by the disk controller, it maps the block to another block it takes from a pool of spares. There are few ways to observe this: - one of the S.M.A.R.T. counts goes up - there may have been an extra bit of latency due to this procedure. When a bad block is detected during a read by the controller, it retries in case that works. If so, it will remap the block on the assumption that that the original block is no longer reliable. If retrying fails, the drive reports that failure. Generally speaking, the correct things to do upon a real disk read failure is: - backup your disks in case subsequent steps curdle your data. - determine what file-system structure just took a bullet. You might have to recover from a backup. If the hit is to metadata, an fsck(8) might be able to fix it. - after these forensics, write something to the bad block. The controller will automatically remap the block. _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
