linux-kernel - Re: Linux kernel - Libata bad block error handling to user mode program

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 5 Mar 2010 13:04:26 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Greg Freemyer <greg.freemyer@...il.com>
Cc:	Mike Hayward <hayward@...p.net>, foosaa@...il.com,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	linux-ide@...r.kernel.org, jens.axboe@...cle.com,
	linux-mm@...ck.org
Subject: Re: Linux kernel - Libata bad block error handling to user mode 
 program

> For clarity, most ATA class disk drives are spec'ed to have one
> non-recoverable error per 150TB or so of writes.  Disk drives do blind
> writes.  (ie. They are not verified).  So we should all expect to have
> the occasional silent data corruption on write.  The problem is
> compounded with bad cables, controllers, RAM, etc.

Cable errors should only be a PATA issue, SATA protects the command block
and the data.

> The only way for the linux kernel even attempt to fix that is for it
> to do a read verify on everything it writes.  For the vast majority of
> uses that is just not acceptable for performance reasons.

It's also the wrong layer

> OTOH, if data integrity is of the utmost for you, then you should
> maintain a md5hash or similar for your critical files and verify them
> any time you make a copy.  btrfs may offer a auto read-verify.  I
> don't know much about btrfs.

If you deal with utterly enormous amounts of data (as some clusters and
the like do) you protect your data from application to application layer.
It leaves ECC protected memory and it comes back to ECC protected memory
with a hash. That covers a lot of the errors by the OS, hardware, cables,
busses - even drive memory.

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