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:48:23 +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 D0FDE20DC1FB for ; Mon, 8 Feb 2016 17:48:22 +0100 (CET) Date: Mon, 8 Feb 2016 17:48:22 +0100 From: Arno Wagner Message-ID: <20160208164822.GC5543@tansi.org> References: <20160205155743.GA32705@tansi.org> <56B5356B.3030704@whgl.uni-frankfurt.de> <20160206025854.GA5986@tansi.org> <56B56605.4030907@whgl.uni-frankfurt.de> <20160207070958.35502402ED@darkstar.media.mit.edu> <20160207231750.GB29215@tansi.org> <20160208020631.E16BA402ED@darkstar.media.mit.edu> <56B80183.60006@whgl.uni-frankfurt.de> <20160208034324.790B2402ED@darkstar.media.mit.edu> <56B81A4E.9090909@whgl.uni-frankfurt.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56B81A4E.9090909@whgl.uni-frankfurt.de> 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 05:32:14 CET, Sven Eschenberg wrote: > > > Am 08.02.2016 um 04:43 schrieb f-dm-c@media.mit.edu: > > > Date: Mon, 8 Feb 2016 03:46:27 +0100 > > > From: Sven Eschenberg > > > > > If a sector fails, it is not that uncommon that a whole chunk of > > > consecutive sectors fail (for rotating disks that is). > > > >Oh, come on. A one-meg gap is 256 4K sectors and 1024 1K sectors. > > > >I've never seen anything take out more than a handful of sectors > >adjacent to each other unless the disk has completely failed. > >Anything that's chewing up multiple megs or tens of megs at the start > >of your FS is likely to destroy any other random parts of it as well. > > > >Okay, how about a -10- meg gap? That enough? > > Well, I've seen several thoundand adjacent sectors going down. And > not just once. Same here. > As I pointed out creating a filesystem can easily destroy both > headers, even though many FSes have a rather thin metadata > structure. Another neat example mdadm - default is header at 4k > (primary header will be damaged) followed by a bad block list and > and intent bitmap. The size of those can vary afaik. > > To be honest, I am not completely sure what a good offset would be. I like the end, because it is clear and far away. It is also what md-RAID for superblock 0.90 does. Non-redudancy during resize is not an issue, as anybody sane will only resize with a header-backup done before. Insane people will manage to screw up anyways, nothing we can do about that. Resize is a dangerous operation, no way around that. We can prevent people from hosing their LUKS container when creating filesysems on it though, or partition sectors or the like. Regards, Arno -- 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 "news" is "something that hardly ever happens." -- Bruce Schneier