linux-kernel - Re: [PATCH 41/44 take 2] [UBI] gluebi unit header

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 17 Feb 2007 21:02:17 -0600
From:	Josh Boyer <jwboyer@...ux.vnet.ibm.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Artem Bityutskiy <dedekind@...radead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Christoph Hellwig <hch@...radead.org>,
	Frank Haverkamp <haver@...t.ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	David Woodhouse <dwmw2@...radead.org>
Subject: Re: [PATCH 41/44 take 2] [UBI] gluebi unit header

On Sun, Feb 18, 2007 at 03:15:23AM +0100, Arnd Bergmann wrote:
> On Sunday 18 February 2007 03:04, Josh Boyer wrote:
> > No, the MTD interface isn't flawed.  gluebi is present to make things like
> > JFFS2 work on top of UBI volumes with very little adaptations.  If you go
> > changing _every_ MTD user to now use either an MTD device or a native UBI
> > device, then the code for those users just gets bloated.
> 
> Right, that was my point. If the MTD API in the kernel is not flawed, why
> do we need the 'native' UBI interface? Just merge gluebi into UBI and
> get rid of the extra abstraction.

That suggestion came up several times.  gluebi represents a compromise
between the two groups.  IIRC, the issue was that representing UBI volumes
as MTD devices only makes sense in the dynamic volume case.  Static UBI
volumes require special write/update handling and so there was a need for
a native interface anyway.

> 
> > Assuming your SD card isn't doing wear-leveling itself within the device,
> > yes that is what you would get.  
> 
> While probably all modern SD cards have some amount of wear leveling
> built in, I wouldn't want to rely on that for anything but the simple
> large-file-on-fatfs (jpeg or mp3) case. Using UBI on top of the
> native wear-leveling sounds like the right solution.

Yeah.  Unfortunately, SD/USB/CF cards are all in sort of an awkward spot
when it comes to things like that.  They don't expose the raw flash
underneath, and they don't provide any indication of how robust the
built in wear-leveling is.  Ugh.

> > Or you could do something slightly more sane 
> > and use:
> > 
> > 1. MMC
> > 2. block2mtd
> > 3. JFFS2
> 
> Not on a 4GB SD medium, with the current jffs2 version. The problem
> is that jffs2 doesn't scale that well, so you want a different fs.

Oh, believe me I know. :)

> Since logfs isn't stable yet, you end up with something like ext3,
> which in turn means that you need a UBI-like concept to avoid
> wearing out the blocks that store your metadata.

That just sounds like we need Jörn to get off his butt and finish logfs ;)
Seriously, until something like that is done we'll be stuck with some not
so pleasant solutions for these kind of devices.

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