linux-kernel - Re: Problem with ata layer in 2.6.24

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]

Message-ID: <alpine.LNX.1.00.0801291354240.13593@iabervon.org>
Date:	Tue, 29 Jan 2008 14:14:13 -0500 (EST)
From:	Daniel Barkalow <barkalow@...ervon.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
cc:	Richard Heck <rgheck@...jweil.com>,
	Gene Heskett <gene.heskett@...il.com>,
	Zan Lynx <zlynx@....org>,
	Calvin Walton <calvin.walton@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux ide Mailing list <linux-ide@...r.kernel.org>
Subject: Re: Problem with ata layer in 2.6.24

On Tue, 29 Jan 2008, Alan Cox wrote:

> > The SCSI error reporting really ought to include a simple interpretation 
> > of the error for end users ("The drive doesn't support this command" "A 
> > sector's data got lost" "The drive timed out" "The drive failed" "The 
> > drive is entirely gone"). There's too much similarity between the message 
> > you get when you try a SMART test that doesn't apply to the drive and what 
> > you get when the drive is broken.
> 
> That would be the SCSI verbose messages option. I think the Eric
> Youngdale consortium added it about Linux 1.2. Nowdays its always built
> that way.

I've seen a lot of verbosity out of SCSI messages, but I haven't seen a 
straightforward interpretation of the problem in there. It's all 
information useful for debugging, not information useful for system 
administration.

> > And it's possible that the error recovery is suboptimal in some cases. It 
> > seems to like resetting drives too much; perhaps if it keeps seeing the 
> > same problem and resetting the drive, it should decide that the drive's 
> > error reporting is just bad and just ignore that error like the old IDE 
> > did (but, in this case, after saying what it's doing).
> 
> Nothing like casually praying the users data hasn't gone for a walk is
> there. If we don't act on them the users don't report them until
> something really bad occurs so that isn't an option.

On the other hand, bringing the system down because a device is 
misbehaving is a poor idea. I've personally recovered most of the data off 
of a dying drive because the system was willing to let me keep using the 
drive anyway; IIRC, the drive didn't work at all after a reboot, so I 
would have lost all the data instead of only a little had the system 
insisted on a perfectly functioning drive in order to use it at all.

There ought to be some middle ground between doing nothing until the 
computer really breaks and breaking the computer before then, but that's 
an issue not specific to libata.

	-Daniel
*This .sig left intentionally blank*
--
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/