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: <20070319170838.GP4892@waste.org>
Date:	Mon, 19 Mar 2007 12:08:38 -0500
From:	Matt Mackall <mpm@...enic.com>
To:	Josh Boyer <jwboyer@...ux.vnet.ibm.com>
Cc:	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 Sun, Mar 18, 2007 at 03:31:50PM -0500, Josh Boyer wrote:
> On Sun, Mar 18, 2007 at 02:18:12PM -0500, Matt Mackall wrote:
> > 
> > I'm well aware of all that. I wrote a NAND driver just last month.
> > Let's consider this table:
> > 
> > HARD drives                          MTD device
> > Consists of sectors                  Consists of eraseblocks
> > Sectors are small (512, 1024 bytes)  Eraseblocks are larger (32KiB, 128KiB)
> > read sector and write sector         read, write, and erase block
> > Bad sectors are re-mapped            Bad eraseblocks are not hidden
> > HDD sectors don't wear out	     Eraseblocks get worn-out
>  N/A                                   NAND flash addressed in pages
>  N/A                                   NAND flash has OOB areas
>  N/A (?)                               NAND flash requires ECC

Disks have OOB areas with ECC, it's just nicely hidden inside the
drive. They also typically have physical sectors bigger than 512
bytes, again hidden.

> > If the end goal is to end up with something that looks like a block
> > device (which seems to be implied by adding transparent wear leveling
> 
> Nope, not the end goal.  It's more about wear-leveling across the entire
> flash chip than it is presenting a "block like" device.

It seems to be about spanning devices and repartitioning as well.
Hence the analogy with LVM.

> > and bad block remapping), then I don't see any reason it can't be done
> > in device mapper. The 'smarts' of mtdblock could in fact be pulled up
> 
> There is nothing smart about mtdblock.  And mtdblock has nothing to do
> with UBI.

Note the scare quotes. Device mapper runs on top of a block device.
And mtdblock is currently the block interface that MTD exports. And it
has 'smarts' that hide handling of sub-eraseblock I/O. I'm clearly
talking about an approach that doesn't involve UBI at all.

> > In the end, a block device is something which does random access
> > block-oriented I/O. Disk and NAND both fit that description.
> 
> NAND very much doesn't fit the "random access" part of that.  For writes
> you have to write in incrementing pages within eraseblocks.

And? You can't do I/O smaller than a sector on a disk.

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