On 20 Nov 2022 at 22:29, Barry wrote: From: Barry <barry@xxxxxxxxxxxxxxxx> Subject: Re: It's a brick :-<( Date sent: Sun, 20 Nov 2022 22:29:56 +0000 To: "D. Hugh Redelmeier" <hugh@xxxxxxxxxx>, Community support for Fedora users <users@xxxxxxxxxxxxxxxxxxxxxxx> Send reply to: Community support for Fedora users <users@xxxxxxxxxxxxxxxxxxxxxxx> > > > > On 20 Nov 2022, at 18:51, D. Hugh Redelmeier <hugh@xxxxxxxxxx> wrote: > > > > | 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. > > Mapping of bad blocks only happens on write. > So multiple reads of a bad block will consistently fail. > Not always the case. Going back to the old DOS days, believe the OS would try 3 times before giving the abort/retry/ignore error message, and sometimes many retires would get a good read... Once had a co-worker that had a critical drive fail, but was able to get the critical files she needed. Ran GRC Spinrite on the 60G disk, and it took 4 days of running to finish. The drive was still very corrupted, but was able to mount with Linux and the sub directory with the files needed was readable, and copied to another disk, and were all good really lucky. Had another co-worker had a disk that had an obviously burned chip on disks controller. Found the exact same disk on ebay (used) with matching model number for $20. Swapped the board, and the data was 100%, but copied everything to a brand new disk.. But of course had other disks that were totally bad. Use to show students and old Seagate 40M disk that had a full head crash. Had a collection of various sized drives to show how things had changed from the old 20M Seagate drives thru the many years... > Barry > > > > > 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 > _______________________________________________ > 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 +------------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor (Retired) mailto:mikes@xxxxxxxx mailto:msetzerii@xxxxxxxxx Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ +------------------------------------------------------------+ _______________________________________________ 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