[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1174478263.10840.56.camel@localhost.localdomain>
Date: Wed, 21 Mar 2007 12:57:42 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Jörn Engel <joern@...ybastard.org>
Cc: Matt Mackall <mpm@...enic.com>,
Josh Boyer <jwboyer@...ux.vnet.ibm.com>,
Artem Bityutskiy <dedekind@...radead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Frank Haverkamp <haver@...t.ibm.com>,
Christoph Hellwig <hch@...radead.org>,
David Woodhouse <dwmw2@...radead.org>
Subject: Re: [PATCH 00/22 take 3] UBI: Unsorted Block Images
On Wed, 2007-03-21 at 12:35 +0100, Jörn Engel wrote:
> Even if such flashes still contain a bootloader and a kernel, that will
> occupy less than 1% of the device. Wear leveling across the device is
> fairly pointless here. This is what I designed LogFS for.
Still you need to have a solution for handling bitflips in those
bootloader and kernel areas.
I don't dispute, that on a Terrabyte solid state disk which is used in a
totally different way, UBI is not necessarily the right tool.
> There is some middle ground where a combination of UBI and LogFS may
> make sense. LogFS can still make sense for devices as small as 64MiB.
> But I'm not too concerned about that because flashes will continue to
> grow and the advantages of cross-device wear leveling will continue to
> diminish.
Flashes will grow, but this will not change the embedded use case with a
relativly small FLASH and the bootloader / kernel / rootfs / datafs
scenario, where UBI is the right tool to use.
There is no hammer for all nails and I don't see device mapper doing
what UBI does right now.
tglx
-
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