Re: Determining which file is at a given LBA offset; was: HDD error: Current_Pending_Sector

[Andy Smith]

Hi,

On Tue, Feb 20, 2024 at 07:53:38PM -0500, Default User wrote:
> Note: I occurs to me that another idea would be to simply delete all
> files from the "bad" drive, then rsync everything fresh from the "good"
> drive back onto the "bad" drive.  

You can do it in one step with rsync --delete … which will delete
anything that doesn't exist on the source.

> IIUC, that would the cause the "bad" sector to be retired, and replaced
> by a "good" sector. 

Yes, a lot of the time a new write is successful and when it's not
it will be remapped. As long as the remapped sector count doesn't
keep going up I'd be fairly comfortable in continuing to use the
drive (assuming backups exist) s while longer.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Determining which file is at a given LBA offset; was: HDD error: Current_Pending_Sector

[Default User]

On Tue, 2024-02-20 at 21:36 +, Michael Kjörling wrote:
> On 20 Feb 2024 12:51 -0500, from hunguponcont...@gmail.com (Default
> User):
> > But since the sector already can not be read, How can it be re-
> > written
> > to a "good" sector?
> 
> Generally, it can't. It will be remapped if necessary when something
> else is written to that sector.
> 
> 
> > If I knew which file (if any) is using the bad sector, I could try
> > just
> > deleting that file from the "bad" drive, then copy the same file
> > over
> > from the "Good" drive, at which time the bad sector "should" be
> > retired, and replaced by a good sector.
> 
> Assuming ext[234]fs, it looks like you can use tune2fs, udisks and
> debugfs to determine the pathname to the file at a given LBA offset.
> See
> http://www.randomnoun.com/wp/2013/09/12/determining-the-file-at-a-specific-vmdk-offset/
> 



Hi, Michael!

I forgot to say that the filesystem of the "bad" drive is a single
partition, formatted as ext4. And the sector and block sizes both seem
to be 512b.

Per sudo fdisk -l /dev/sdb:


Disk /dev/sdb: 3.64 TiB, 4000752599040 bytes, 7813969920 sectors
Disk model: My Passport 2627
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: ----

Device StartEndSectors  Size Type
/dev/sdb1   2048 7813967871 7813965824  3.6T Linux filesystem
-

Regarding: 
>. . . it looks like you can use tune2fs, udisks and
>debugfs to determine the pathname to the file at a given LBA offset.
>See 
>http://www.randomnoun.com/wp/2013/09/12/determining-the-file-at-a-specific-vmdk-offset/
>that could be a little above my current level of competence. But I
>will try to read up on it.

Note: I occurs to me that another idea would be to simply delete all
files from the "bad" drive, then rsync everything fresh from the "good"
drive back onto the "bad" drive.  

IIUC, that would the cause the "bad" sector to be retired, and replaced
by a "good" sector. 

That might be easier than everything else mentioned so far. 

Re: Determining which file is at a given LBA offset; was: HDD error: Current_Pending_Sector

[Michael Kjörling]

On 20 Feb 2024 12:51 -0500, from hunguponcont...@gmail.com (Default User):
> But since the sector already can not be read, How can it be re-written
> to a "good" sector?

Generally, it can't. It will be remapped if necessary when something
else is written to that sector.


> If I knew which file (if any) is using the bad sector, I could try just
> deleting that file from the "bad" drive, then copy the same file over
> from the "Good" drive, at which time the bad sector "should" be
> retired, and replaced by a good sector.

Assuming ext[234]fs, it looks like you can use tune2fs, udisks and
debugfs to determine the pathname to the file at a given LBA offset.
See 
http://www.randomnoun.com/wp/2013/09/12/determining-the-file-at-a-specific-vmdk-offset/

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”