[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADRPPNT-akj5KBQKdRaFrA2XpLU6-xtuRduzDYEWjv_dzVmTAA@mail.gmail.com>
Date: Mon, 19 Dec 2011 19:05:26 +0800
From: Li Yang <leoli@...escale.com>
To: Scott Wood <scottwood@...escale.com>
Cc: LiuShuo <b35362@...escale.com>, dedekind1@...il.com,
shuo.liu@...escale.com, dwmw2@...radead.org,
Artem.Bityutskiy@...ia.com, linux-mtd@...ts.infradead.org,
linuxppc-dev@...ts.ozlabs.org, akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support
large-page Nand chip
On Sat, Dec 17, 2011 at 1:59 AM, Scott Wood <scottwood@...escale.com> wrote:
> On 12/15/2011 08:44 PM, LiuShuo wrote:
>> hi Artem,
>> Could this patch be applied now and we make a independent patch for bad
>> block information
>> migration later?
>
> This patch is not safe to use without migration.
Hi Scott,
We agree it's not entirely safe without migrating the bad block flag.
But let's consider two sides of the situation.
Firstly, it's only unsafe when there is a need to re-built the Bad
Block Table from scratch(old BBT broken). But currently there is no
easy way to do that(re-build BBT on demand), which means it's not a
common problem that we can easily address now.
Secondly, even if the previous said problem happens(BBT broken). We
can still recover all the data if we overrule the bad block flag.
Only the card is not so good to be used again, however, it can be used
if we take the risk of losing data from errors that ECC can't
notice(low possibility too).
Finally, I don't think this is a blocker issue but a better to have enhancement.
- Leo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists