linux-kernel - Re: SATA hdd refuses to reallocate a sector?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 24 Jun 2013 08:19:55 +0200
From:	Marcus Overhagen <marcus.overhagen@...il.com>
To:	Mark Lord <mlord@...ox.com>
Cc:	Pavel Machek <pavel@....cz>,
	kernel list <linux-kernel@...r.kernel.org>,
	linux-ide@...r.kernel.org, tj@...nel.org
Subject: Re: SATA hdd refuses to reallocate a sector?

> > root@amd:~# dd if=/dev/sda4 of=/dev/zero bs=1 skip=8958947328
> > > dd: reading `/dev/sda4': Input/output error
> > > 0+0 records in
> > > 0+0 records out
> > > 0 bytes (0 B) copied, 5.05805 s, 0.0 kB/s
> >
> > I once noticed a similar problem. The trouble is that the kernel
> > always seems to be doing a larger read access that failes for this
> > sector, and the write is never executed.
>
> And returns success writing? That's pretty antisocial :-(.

On a second look i see that you have if and of reversed in the dd command.
However, what I was referring to was that writing a single sector with dd
will fail with a io error because the kernel first seems to do a larger read.

> ...but it does not do the trick :-(. It behaves strangely as if it was
> still cached somewhere. Do I need to turn off the write back cache?

I used hdparm --write-sector successfully to fix a single sector where
dd would fail, but I really don't know what going on with your disk. I
guess your harddisk is having some more issues than this single
sector. If you haven't done it yet, make a complete backup!

Your original post contained:

> end_request: I/O error, dev sda, sector 961237184
> Buffer I/O error on device sda4, logical block 17498759
> Buffer I/O error on device sda4, logical block 17498760
> Buffer I/O error on device sda4, logical block 17498761
> Buffer I/O error on device sda4, logical block 17498762
> Buffer I/O error on device sda4, logical block 17498763
> Buffer I/O error on device sda4, logical block 17498764
> Buffer I/O error on device sda4, logical block 17498765
> Buffer I/O error on device sda4, logical block 17498766
> Buffer I/O error on device sda4, logical block 17498767
> Buffer I/O error on device sda4, logical block 17498768

So assuming(!) that sector 961237184of sda  is logical block 17498759
from sda4, you may need to write all sectors 961237184 to 961237193.

However, regarding the smart data, the drive still thinks that it's
pretty healthy, only 3 reallocated sectors, and no pending.

> 5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       3
> 197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
> 198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0

Perhaps writing the whole disk with dd and a larger blocksize would
ill work? something like

dd if=/dev/zero of=/dev/sda bs=1M

You shouldn't have any partiton monted when doing so. All data ist
lost after that is finished. then you can look into the smart data to
see how many sectors were reallocated, and decide if you want to trash
the disk.

regards
Marcus

On Mon, Jun 24, 2013 at 12:35 AM, Mark Lord <mlord@...ox.com> wrote:
> On 13-06-23 05:51 PM, Pavel Machek wrote:
>> On Sun 2013-06-23 17:27:52, Mark Lord wrote:
>>
>>> For all existing drives out there, that's a 512 byte unit.
>>
>> I guessed so. (It would be good to actually document it, as well as
>> documenting exactly why it is dangerous. Is it okay to send patches?)
>
> Absolutely.  Please, even!
>
>> Well, I definitely have more than one bad sector, but I did try to
>> read exactly the same sector and it failed. See below.
> ..
> read failed.
> write works.
> read failed.
> write works.
> read works.
> dd failed.
> read works.
> read works.
> read failed.
>
> Odd.  The drive must be furiously reshuffling sectors or something,
> or more likely pushing a piece of dirt around scuffing up more bits.
>
> hdparm generally talks directly to a drive, not through the block
> or filesystem layers.  So the block, filesystem, and page-cache stuff
> don't know anything about --read-sector and --write-sector.
>
> Cheers
> --
> Mark Lord
> Real-Time Remedies Inc.
> mlord@...ox.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/