Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966115AbbKFVFa (ORCPT ); Fri, 6 Nov 2015 16:05:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:57690 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965993AbbKFVF3 (ORCPT ); Fri, 6 Nov 2015 16:05:29 -0500 Subject: Re: [dm-devel] [PATCH 0/4] dm verity: add support for error correction To: device-mapper development References: <1446688954-29589-1-git-send-email-samitolvanen@google.com> <563B066C.6050202@redhat.com> <20151106190634.GA2813@google.com> <563CFD6F.4040009@redhat.com> <20151106202750.GA11849@google.com> Cc: Will Drewry , Kees Cook , Mike Snitzer , Mandeep Baines , linux-kernel@vger.kernel.org, Mikulas Patocka , Mark Salyzyn From: Zdenek Kabelac Organization: Red Hat Message-ID: <563D1614.5010501@redhat.com> Date: Fri, 6 Nov 2015 22:05:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151106202750.GA11849@google.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1288 Lines: 33 Dne 6.11.2015 v 21:27 Sami Tolvanen napsal(a): > On Fri, Nov 06, 2015 at 08:20:15PM +0100, Zdenek Kabelac wrote: >> i.e. you have 1G of space - you want to give 250MB as 'redundancy' - >> so create 4 partition.... well data safety has it's price - user should choose what he prefers - more games and videos or more safety... > > We cannot afford to set aside 25% of read-only partition space for > redundancy on mobile devices, and would rather not impact performance > any more than dm-verity already does. With error correction we have > 0.8% space overhead in our use case and no performance degradation if > the partition is not corrupted. > I'm probably missing here some hw knowledge here - but if you loose a flash block of some size - then you typically get 'error' for all bytes the sector/block. So how do you want to correctly 'restore' missing full sectors with just 0.8% data overhead ?? Or is the device which fails to correct block returning something 'still usable' (since e.g. SATA disk certainly not) Zdenek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/