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 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from a.ns.miles-group.at ([95.130.255.143] helo=radon.swed.at) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1XiUb9-0008RO-K3 for linux-mtd@lists.infradead.org; Sun, 26 Oct 2014 20:39:36 +0000 Message-ID: <544D5BEC.50802@nod.at> Date: Sun, 26 Oct 2014 21:39:08 +0100 From: Richard Weinberger MIME-Version: 1.0 To: Tanya Brokhman , dedekind1@gmail.com Subject: Re: [RFC/PATCH 0/5 v2] mtd:ubi: Read disturb and Data retention handling References: <1414331342-27839-1-git-send-email-tlinder@codeaurora.org> In-Reply-To: <1414331342-27839-1-git-send-email-tlinder@codeaurora.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: linux-arm-msm@vger.kernel.org, linux-mtd@lists.infradead.org List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 result > in uncorrectable ECC errors. This is known as the read disturb or data > retention. > > Today’s Linux NAND drivers implementation doesn’t address 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’s NAND devices is very low. > > With the evolution of NAND devices and the requirement for a “long life” > NAND flash, read disturb and data retention can no longer be ignored > otherwise there will be data loss over time. > > 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 after N reads (to detect read disturb issues). Is this correct? Currently users of UBI do this by having cron jobs which read the complete 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 and 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 it is time to trigger a re-read of a PEB. This daemon can also store and load the timestamp values and counters from 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 data. All in all, I like the idea but changing/extending the on-disk layout is overkill IMHO. Thanks, //richard