linux-kernel - Re: [PATCH 00/22 take 3] UBI: Unsorted Block Images

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20070318162720.GI10459@waste.org>
Date:	Sun, 18 Mar 2007 11:27:20 -0500
From:	Matt Mackall <mpm@...enic.com>
To:	Artem Bityutskiy <dedekind@...radead.org>
Cc:	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>,
	Josh Boyer <jwboyer@...ux.vnet.ibm.com>
Subject: Re: [PATCH 00/22 take 3] UBI: Unsorted Block Images

On Wed, Mar 14, 2007 at 05:19:34PM +0200, Artem Bityutskiy wrote:
> Hello,
> 
> This patch-set contains UBI, which stands for Unsorted Block Images. This
> is closely related to the memory technology devices Linux subsystem (MTD),
> so this new piece of software is from drivers/mtd/ubi.
> 
> In short, UBI is kind of LVM layer but for flash (MTD) devices. It makes
> it possible to dynamically create, delete and re-size volumes. But the
> analogy is not full. UBI also takes care of wear-leveling and bad
> eraseblocks handling, so UBI completely hides 2 aspects of flash chips
> which make them very difficult to work with:
> 
> 1. wear of eraseblocks;
> 2. bad eraseblocks.

Forgive my ignorance, but why did you not implement the two features
above as device mapper layers instead? A device mapper can arbitrarily
transform I/O addresses and contents and has direct access to the
mapped device's ioctl interfaces, etc. 

Writing a mapper that's driven by out of band data on the underlying
device can be done in a couple hundred lines of code. I've done it to
implement an MD5 integrity checking layer. In this case, all the I/Os
were simply remapped to be above the on-disk MD5 table and expanded to
be at least the hashed cluster size.

Even if the device mapper API is not completely up to the task (which
I strongly suspect it is), it would seem simpler to extend it than to
add 14000 lines of parallel subsystem.

-- 
Mathematics is the supreme nostalgia of our time.
-
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/