From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from v6.tansi.org (mail.tansi.org [87.118.116.4]) by mail.server123.net (Postfix) with ESMTP for ; Mon, 8 Feb 2016 17:57:49 +0100 (CET) Received: from gatewagner.dyndns.org (77-57-36-72.dclient.hispeed.ch [77.57.36.72]) by v6.tansi.org (Postfix) with ESMTPA id A9C8020DC1FB for ; Mon, 8 Feb 2016 17:57:48 +0100 (CET) Date: Mon, 8 Feb 2016 17:57:48 +0100 From: Arno Wagner Message-ID: <20160208165748.GE5543@tansi.org> References: <56B5356B.3030704@whgl.uni-frankfurt.de> <20160206025854.GA5986@tansi.org> <56B56605.4030907@whgl.uni-frankfurt.de> <20160206100140.GU13740@yeono.kjorling.se> <56B641C2.4070400@whgl.uni-frankfurt.de> <20160206190916.GA20801@yeono.kjorling.se> <56B646EA.1050100@whgl.uni-frankfurt.de> <20160207230502.GA29215@tansi.org> <56B7E07B.2000906@whgl.uni-frankfurt.de> <20160208113404.GG6060@yeono.kjorling.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20160208113404.GG6060@yeono.kjorling.se> Subject: Re: [dm-crypt] The future of disk encryption with LUKS2 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On Mon, Feb 08, 2016 at 12:34:04 CET, Michael Kj=F6rling wrote: > On 8 Feb 2016 01:25 +0100, from sven@whgl.uni-frankfurt.de (Sven Eschenbe= rg): > > I always > > wondered how a HDD exactly behaves when power fails, while a sector > > is in transit. My best hope is, that the CRC at the end of the > > sector does not match and an error is returned on the next read? >=20 > That's the theory; if a sector write is interrupted half way through > (regardless of the reason), then the FEC data doesn't match the sector > payload data. In this case, the difference is very likely large enough > that the error cannot be corrected using the FEC data, so you get a > read error back instead. >=20 > _Unfortunately_, theory and practice don't always agree. I think it > was Google that did a study on storage errors not all that long ago, > and one conclusion was that silent read errors (where you do get data > back from the drive, but that data is not the same as was originally > written), while rare, happens with a high enough probability to > warrant consideration in large storage systems. I think I read that paper (if so, it was pretty bad) and if I remember correctly, they did not diagnose what the issues were, just that they had bad data at the end in main memory. >From my experience shoveling a few hundred TBs of research data around when 200GB disks where standard, the only undetected errors I ever found were due to memory corruption due to a weak RAM bit=20 in one server that did not have ECC memory. Those amounted to=20 3 errors in 30TBs of recorded data. I never had undetected read errors from disk (and since all data was bzip2 compressed,=20 errors would have been found), so I tend to view these as not a disk problem, but likely happening someplace after the data leaves the disk. =20 Regards, Arno --=20 Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. -- Plato If it's in the news, don't worry about it. The very definition of=20 "news" is "something that hardly ever happens." -- Bruce Schneier