Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1262817 > unrolled thread

[PATCH 0/4] dm verity: add support for error correction

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/4] dm verity: add support for error correction Sami Tolvanen <samitolvanen@google.com> - 2015-11-05 03:10 +0100
    [PATCH 1/4] dm verity: clean up duplicate hashing code Sami Tolvanen <samitolvanen@google.com> - 2015-11-05 03:10 +0100
    [PATCH 4/4] dm verity: ignore zero blocks Sami Tolvanen <samitolvanen@google.com> - 2015-11-05 03:10 +0100
    [PATCH 3/4] dm verity: add support for forward error correction Sami Tolvanen <samitolvanen@google.com> - 2015-11-05 03:10 +0100
      Re: [PATCH 3/4] dm verity: add support for forward error correction kbuild test robot <lkp@intel.com> - 2015-11-05 06:40 +0100
    [PATCH 2/4] dm verity: separate function for parsing opt args Sami Tolvanen <samitolvanen@google.com> - 2015-11-05 03:10 +0100
    Re: [PATCH 0/4] dm verity: add support for error correction Milan Broz <mbroz@redhat.com> - 2015-11-05 08:40 +0100
      Re: [PATCH 0/4] dm verity: add support for error correction Sami Tolvanen <samitolvanen@google.com> - 2015-11-05 18:40 +0100
        Re: [PATCH 0/4] dm verity: add support for error correction Mike Snitzer <snitzer@redhat.com> - 2015-11-09 17:40 +0100
          Re: [PATCH 0/4] dm verity: add support for error correction Sami Tolvanen <samitolvanen@google.com> - 2015-11-09 20:20 +0100
            Re: [PATCH 0/4] dm verity: add support for error correction Mike Snitzer <snitzer@redhat.com> - 2015-11-09 21:00 +0100
            Re: [PATCH 0/4] dm verity: add support for error correction Milan Broz <mbroz@redhat.com> - 2015-11-12 11:40 +0100
            Re: [PATCH 0/4] dm verity: add support for error correction Mikulas Patocka <mpatocka@redhat.com> - 2015-11-12 20:00 +0100
      Re: [PATCH 0/4] dm verity: add support for error correction Mikulas Patocka <mpatocka@redhat.com> - 2015-11-06 18:30 +0100
        Re: [PATCH 0/4] dm verity: add support for error correction Sami Tolvanen <samitolvanen@google.com> - 2015-11-06 20:10 +0100
          Re: [dm-devel] [PATCH 0/4] dm verity: add support for error  correction Zdenek Kabelac <zkabelac@redhat.com> - 2015-11-06 20:30 +0100
            Re: [dm-devel] [PATCH 0/4] dm verity: add support for error  correction Sami Tolvanen <samitolvanen@google.com> - 2015-11-06 21:30 +0100
              Re: [dm-devel] [PATCH 0/4] dm verity: add support for error  correction Zdenek Kabelac <zkabelac@redhat.com> - 2015-11-06 22:10 +0100
                Re: [dm-devel] [PATCH 0/4] dm verity: add support for error  correction Sami Tolvanen <samitolvanen@google.com> - 2015-11-06 22:30 +0100
                  Re: [dm-devel] [PATCH 0/4] dm verity: add support for error  correction Mikulas Patocka <mpatocka@redhat.com> - 2015-11-07 16:30 +0100
              Re: [dm-devel] [PATCH 0/4] dm verity: add support for error  correction Mikulas Patocka <mpatocka@redhat.com> - 2015-11-07 16:30 +0100
          Re: [PATCH 0/4] dm verity: add support for error correction Mikulas Patocka <mpatocka@redhat.com> - 2015-11-07 16:20 +0100
            Re: [PATCH 0/4] dm verity: add support for error correction Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-11-09 16:10 +0100

Page 2 of 2 — ← Prev page 1 [2]

#1264861 — Re: [dm-devel] [PATCH 0/4] dm verity: add support for error correction

On Fri, 6 Nov 2015, Sami Tolvanen wrote:

> 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....
> 
> We cannot afford to set aside 25% of read-only partition space for

You can have 20 raid5 legs (with as big chunksizes as possible - so that 
sequential accesses are really sequential when they hit the flash device), 
and that means setting aside only 5%. Or even more legs.

Mikulas

> 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.
> 
> Sami
--
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/

[toc] | [prev] | [next] | [standalone]

#1264859

On Fri, 6 Nov 2015, Sami Tolvanen wrote:

> On Fri, Nov 06, 2015 at 12:23:29PM -0500, Mikulas Patocka wrote:
> > I'm also wondering what is this patch useful for. Disks and flash 
> > controllers have their own error detection and correction
> 
> I think I addressed this earlier. Some storage devices are able to
> correct bit flips, but don't have enough redundancy to correct larger
> errors. Using this patch set we can correct N MiB of consecutive
> corruption anywhere on the partition with the same amount of storage
> overhead.

So, why doesn't the patch correct I/O errors? It is more likely that the 
flash controller returns an I/O error than corrupted data. Why are you 
correcting corrupted data (that is unlikely) and not correcting I/O errors 
that are likely?

> > Another point - if the read-only system partition is experiencing some
> > errors, than the read-write partition will probably have errors too
> 
> On mobile devices, errors in read-only partitions often lead to
> bricked devices while errors in the read-write parts might only lead
> to lost cat photos. There are situations where people would prefer to
> have a working phone even if it fails to store some of their data.

The read-write partition holds compiled applications and I doubt the 
smartphone would work if there were random bits flipped.

> > Do you have some real case where such error corrections 
> > increase longevity of some device?
> 
> Yes, there have been several cases where read-only partition errors
> have rendered a device unusable. The sheer volume of mobile devices
> means that even if a tiny fraction of them suffer from such a problem,
> it's going to affect a large number of people.

Why don't you reflash the device from bootloader? (by holding power and 
volume keys simultaneously on startup and using the fastboot utility)

> > But you can take raid5 in read-only mode, put it on several partitions 
> > protected with dm-verity and you get decent error correction
> 
> I agree. Unfortunately, we don't currently have the luxury of using
> raid on mobile devices.

Why not, it's just a simple kernel option. If raid5 already does data 
correction, there is no reason why to duplicate this work.

> Sami

Mikulas
--
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/

[toc] | [prev] | [next] | [standalone]

#1265751

[Multipart message — attachments visible in raw view] — view raw

On 2015-11-07 10:18, Mikulas Patocka wrote:
>
>
> On Fri, 6 Nov 2015, Sami Tolvanen wrote:
>
>> On Fri, Nov 06, 2015 at 12:23:29PM -0500, Mikulas Patocka wrote:
>>> Do you have some real case where such error corrections
>>> increase longevity of some device?
>>
>> Yes, there have been several cases where read-only partition errors
>> have rendered a device unusable. The sheer volume of mobile devices
>> means that even if a tiny fraction of them suffer from such a problem,
>> it's going to affect a large number of people.
>
> Why don't you reflash the device from bootloader? (by holding power and
> volume keys simultaneously on startup and using the fastboot utility)
Requiring an end user to re-flash their device is not good business 
practice, even if it is a rare occurrence (it adds a potential 
attack-vector for malware, and is decidedly non-trivial to do for 
someone without programming background).  Phones, tablets, and other 
embedded systems are the type of thing where the device needs to be 
usable when the user wants to access it, period.  Minimizing the chances 
of the device not working (even for less common causes like this patch 
tries to protect against) is crucial to making the user experience as 
good as possible (and reducing customer support costs).

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web