| 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
| ||
|
Message-ID: <4D166205.4070205@msgid.tls.msk.ru> Date: Sun, 26 Dec 2010 00:28:37 +0300 From: Michael Tokarev <mjt@....msk.ru> To: Jaap Crezee <jaap@....nl> CC: linux-kernel@...r.kernel.org Subject: Re: Slow disks. 25.12.2010 21:12, Jaap Crezee wrote: > On 12/25/10 13:19, Mikael Abrahamsson wrote: >> On Sat, 25 Dec 2010, Rogier Wolff wrote: >> Read errors will use parity drive and be re-written by the md layer. > > Can you show us *that* code? I don't recall seeing this behaviour.... > Just one read error and "bang". Or does the kernel not report the first > few read errors and just continues without telling us? > I don't like that. With a normal disk without raid I would have had some > log telling me the disk got bad? The code is in the md driver. This behavour is here for several years. If the drive respond in time ofcourse - if it tries to re-read the problematic sector forever and ignores other commands during this time it will be kicked off any array - be it software or hardware. The logs will be in whatever logfile your kernel messages are logged to. And yes, the application which reads the "problematic" area is _not_ notfied, since the data gets restored from other driver - if that was an md array with sufficient redundancy (any non-degraded raid other than raid0). /mjt -- 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