On 20 Nov 2022 at 22:29, Barry wrote:
From: Barry <barry(a)barrys-emacs.org>
Subject: Re: It's a brick :-<(
Date sent: Sun, 20 Nov 2022 22:29:56 +0000
To: "D. Hugh Redelmeier"
<hugh(a)mimosa.com>,
Community support for Fedora users
<users(a)lists.fedoraproject.org>
Send reply to: Community support for Fedora
users <users(a)lists.fedoraproject.org>
> On 20 Nov 2022, at 18:51, D. Hugh Redelmeier <hugh(a)mimosa.com> wrote:
>
> | From: Geoffrey Leach <geoffleach.gl(a)gmail.com>
>
> | 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(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> 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@lists.fedoraproject.org
> Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
+------------------------------------------------------------+
Michael D. Setzer II - Computer Science Instructor
(Retired)
mailto:mikes@guam.net
mailto:msetzerii@gmail.com
Guam - Where America's Day Begins
G4L Disk Imaging Project maintainer
http://sourceforge.net/projects/g4l/
+------------------------------------------------------------+