| 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: <Pine.LNX.4.64.0706202341080.31603@asgard.lang.hm> Date: Wed, 20 Jun 2007 23:45:25 -0700 (PDT) From: david@...g.hm To: David Chinner <dgc@....com> cc: Neil Brown <neilb@...e.de>, Avi Kivity <avi@...o.co.il>, linux-kernel@...r.kernel.org, linux-raid@...r.kernel.org Subject: Re: limits on raid On Thu, 21 Jun 2007, David Chinner wrote: > On Thu, Jun 21, 2007 at 12:56:44PM +1000, Neil Brown wrote: > >> I have that - apparently naive - idea that drives use strong checksum, >> and will never return bad data, only good data or an error. If this >> isn't right, then it would really help to understand what the cause of >> other failures are before working out how to handle them.... > > The drive is not the only source of errors, though. You could > have a path problem that is corrupting random bits between the drive > and the filesystem. So the data on the disk might be fine, and > reading it via a redundant path might be all that is needed. one of the 'killer features' of zfs is that it does checksums of every file on disk. so many people don't consider the disk infallable. several other filesystems also do checksums both bitkeeper and git do checksums of files to detect disk corruption as david C points out there are many points in the path where the data could get corrupted besides on the platter. David Lang - 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