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] [day] [month] [year] [list]
Date:	Sun, 22 Mar 2009 11:15:47 +0900
From:	"Norman Diamond" <n0diamond@...oo.co.jp>
To:	"James Bottomley" <James.Bottomley@...senPartnership.com>,
	"Mark Lord" <liml@....ca>
Cc:	<linux-kernel@...r.kernel.org>, <linux-ide@...r.kernel.org>
Subject: Re: Overagressive failing of disk reads, both LIBATA and IDE

James Bottomley wrote:
> On Thu, 2009-03-19 at 23:32 -0400, Mark Lord wrote:
>> Norman Diamond wrote:
>>> For months I was wondering how a disk could do this:
>>> dd if=/dev/hda of=/dev/null bs=512 skip=551540 count=4  # succeeds
>>> dd if=/dev/hda of=/dev/null bs=512 skip=551544 count=4  # succeeds
>>> dd if=/dev/hda of=/dev/null bs=512 skip=551540 count=8  # fails
>
> This basically means the drive doesn't report where in the requested
> transfer the error occurred.  If we have that information, we'd return all
> sectors up to that LBA as OK and all at or beyond as -EIO, so the
> readahead wouldn't matter.

That's exactly what my submission suggested Linux should do, because that's
exactly what Linux isn't doing.  The defective sector number is 551562.
Linux makes varying decisions on how much to read ahead, and when its
readahead includes the defective sector Linux doesn't do what you and I want
it to do.

The way I discovered the actual defective sector number is that one time
last week I noticed it in dmesg output.  After noticing it, investigation
became a lot easier.  I don't remember if I noticed it for hda (old IDE) or
sda (LIBATA) but either way the drive put the defective sector number in its
error report.  When readahead was long enough to reach sector 551562 the
drive told the PC.

Regarding other threads of this discussion, I/Os are not being merged with 
other processes.  I'm running either Slax or Knoppix from a live CD, and the 
only one accessing the hard drive is me.

In cases where Slax or Knoppix includes a sufficiently recent hdparm, I 
could attempt reads of individual sectors.  551561 is OK.  551563 is OK. 
551562 has an uncorrectable media error.  I had mentioned that the drive has 
egregiously bad firmware (which doesn't excuse Linux).  That includes an 
effort to relocate the sector by using hdparm to write sector 551562, 
whereupon Hitachi drives me crazy.  The drive reports success but subsequent 
reads still fail. 

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ