[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87f94c371003042201n72ce8578vc01331678b52da75@mail.gmail.com>
Date: Fri, 5 Mar 2010 01:01:07 -0500
From: Greg Freemyer <greg.freemyer@...il.com>
To: Mike Hayward <hayward@...p.net>
Cc: 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
> Please let me know if you can prove data corruption. I'm writing a
> sophisticated storage app and would like to know if kernel has such a
> defect. My bet is it's just a drive that is slowly remapping.
>
> - Mike
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.
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.
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.
Greg
--
Greg Freemyer
Head of EDD Tape Extraction and Processing team
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
Preservation and Forensic processing of Exchange Repositories White Paper -
<http://www.norcrossgroup.com/forms/whitepapers/tng_whitepaper_fpe.html>
The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com
--
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