From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Weinberger Subject: Re: [RFC/PATCH 0/5 v2] mtd:ubi: Read disturb and Data retention handling Date: Sun, 26 Oct 2014 21:39:08 +0100 Message-ID: <544D5BEC.50802@nod.at> References: <1414331342-27839-1-git-send-email-tlinder@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from a.ns.miles-group.at ([95.130.255.143]:65275 "EHLO radon.swed.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751609AbaJZUjM (ORCPT ); Sun, 26 Oct 2014 16:39:12 -0400 In-Reply-To: <1414331342-27839-1-git-send-email-tlinder@codeaurora.org> Sender: linux-arm-msm-owner@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org To: Tanya Brokhman , dedekind1@gmail.com Cc: linux-mtd@lists.infradead.org, linux-arm-msm@vger.kernel.org Am 26.10.2014 um 14:49 schrieb Tanya Brokhman: > One of the limitations of the NAND devices is the method used to read > NAND flash memory may cause bit-flips on the surrounding cells and re= sult > in uncorrectable ECC errors. This is known as the read disturb or dat= a > retention. >=20 > Today=E2=80=99s Linux NAND drivers implementation doesn=E2=80=99t add= ress the read disturb > and the data retention limitations of the NAND devices. To date these > issues could be overlooked since the possibility of their occurrence = in > today=E2=80=99s NAND devices is very low.=20 >=20 > With the evolution of NAND devices and the requirement for a =E2=80=9C= long life=E2=80=9D > NAND flash, read disturb and data retention can no longer be ignored > otherwise there will be data loss over time. >=20 > The following patch set implements handling of Read-disturb and Data > retention by the UBI layer. So, your patch addresses the following issue: We need to re-read a PEB after a specific time (to detect bit rot) or a= fter N reads (to detect read disturb issues). Is this correct? Currently users of UBI do this by having cron jobs which read the compl= ete UBI volume and then cause scrub work. The draw back of this is that only UBI payload will be read and not all= data like EC and VID headers. I understand that you want to fix this issue. According to my opinion it is not a good idea to store read counters an= d timestamps into the UBI/Fastmap on-disk layout. Both the read counters and timestamps don't have to be exact values. What about this idea? Add a userspace interface which allows UBI to expose read counters and = last access timestamps. A userspace daemon (let's name it ubihealthd) then can decide whether i= t is time to trigger a re-read of a PEB. This daemon can also store and load the timestamp values and counters f= rom and to UBI. If it misses these meta data some times due to a power cut it won't hurt. We could also add another internal UBI volume which can carry these dat= a. All in all, I like the idea but changing/extending the on-disk layout i= s overkill IMHO. Thanks, //richard