linux-kernel - Re: [PATCH] scsi_lib.c: continue after MEDIUM

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:	Fri, 02 Feb 2007 08:53:27 -0600
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Alan <alan@...rguk.ukuu.org.uk>
Cc:	Ric Wheeler <ric@....com>, Mark Lord <liml@....ca>,
	linux-kernel@...r.kernel.org,
	IDE/ATA development list <linux-ide@...r.kernel.org>,
	linux-scsi <linux-scsi@...r.kernel.org>
Subject: Re: [PATCH] scsi_lib.c: continue after MEDIUM_ERROR

On Fri, 2007-02-02 at 14:42 +0000, Alan wrote:
> > The interesting point of this question is about the typically pattern of 
> > IO errors. On a read, it is safe to assume that you will have issues 
> > with some bounded numbers of adjacent sectors.
> 
> Which in theory you can get by asking the drive for the real sector size
> from the ATA7 info. (We ought to dig this out more as its relevant for
> partition layout too).
> 
> > I really like the idea of being able to set this kind of policy on a per 
> > drive instance since what you want here will change depending on what 
> > your system requirements are, what the system is trying to do (i.e., 
> > when trying to recover a failing but not dead yet disk, IO errors should 
> > be as quick as possible and we should choose an IO scheduler that does 
> > not combine IO's).
> 
> That seems to be arguing for a bounded "live" time including retry run
> time for a command. That's also more intuitive for real time work and for
> end user setup. "Either work or fail within n seconds"

Actually, then I think perhaps we use the allowed retries for this ...

So you would fail a single sector and count it against the retries.
When you've done this allowed retries times, you fail the rest of the
request.

James


-
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/