On Mon, 2007-03-19 at 17:32 -0500, Matt Mackall wrote:
It appears to be, but it is not. You enforce semantics on a device,
which it does not have.
There is a huge difference. Disk block size is 512 byte and FLASH block
size is min 16KiB and up to 256KiB.
Just do the math:
Write sampling data streams in 2KiB chunks to your uber devicemapper on
a 1GiB device with 64KiB erase block size:
Fine grained FLASH aware writes allow 32 chunks in a block without
erasing the block.
Your method erases the block 32 times to write the same amount of data.
Result: You wear out the flash 32 times faster. Cool feature.
We can do it under _any_ circumstances and that _does_ change it.
Implementing a clever block device layer on top of UBI is simple and
would provide FLASH page sized I/O, i.e. 2Kib in the above example.
I'm impressed. How exactly are "some tapes" comparable to FLASH chips ?
Your next proposal is to throw away MTD-utils and use "mt" instead ?
No, it is not. You get the absolute sector address of your second stage
and this is a complete nobrainer. The translation is done in the DISK
device.
You simply ignore the fact, that inside each disk, USB Stick, CF-CARD,
whatever - there is a more or less intellegent controller device, which
does the mapping to the physical storage location. There is _NO_ such
thing on a bare FLASH chip.
It does not matter, whether your embedded device had more NAND space
than my old CP/M machines floppy. It simply matters, that even the old
CP/M floppy device had some rudimentary intellence on board.
Furthermore I want to be able to get the bitflip correction on my second
stage loader / kernel in the same safe way as we do it for everything
else and still be able to bootstrap that from an extremly small
bootloader.
How exactly does device mapper:
A) across device wear levelling ?
B) dynamic partitioning for FLASH aware file systems ?
C) across device wear levelling for FLASH aware file systems ?
D) background bit-flip corrections (copying affected blocks and recylce
the old one) ?
E) allow position independent placement of the second stage bootloader ?
Yes, it is in your picture, but:
1) it excludes FLASH aware file systems and UBI does not.
2) your picture does still not explain how it does achive the above A),
B), C), D) and E)
Your extra path for partitioning(4) and JFFS2 is just a weird hack,
which makes your proposal completely absurd.
Let me draw an UBI picture:
VFS -Layer
|
(Future VFS-crypto)
/ \
| |
______ device mapper / fs |
/ | |
/ | |
| Do whatever you don't |
| want to do with FLASH |
| whether it makes sense |
| or not. |
| | |
Block layer UBI block device Flash aware filesystems
| \ /
device \ /
driver |
| |
_____|_______ |
| | |
| Device | UBI
| resident | |
| "UBI" | |
|___________| |
|
MTD-CORE
|
nand base driver
/ | \
device driver device driver device driver
| |
NAND NAND NAND
No notes: it's simple and self explaining.
Oh well, a seperate bad block remapper. And how is the logical mapping
of wear levelled erase blocks done ?
And how is the wear levelling done on this logical device in
devicemapper ?
How is ensured, that the wear average is maintained also across the
partitions which are used by JFFS2 or other FLASH aware filesystems ?
LogFS can easily leverage UBI's wear algorithm.
1. On top of a clever block device.
2. UBI can do snapshots by design.
3. Encryption should be done on the VFS layer and not below the
filesystem layer. Doing it inside the block layer or the device mapper
is broken by design.
You still did not explain how devicemapper does:
- across device wear levelling
- dynamic partitioning for FLASH aware file systems
- across device wear levelling for FLASH aware file systems
- simple boot loader support
- fine grained I/O
UBI is not devicemappers little brother. It is the software version of
the silicon in a CF-CARD / USB-Stick, but it does a better job and
allows clever usage of FLASH aside of enforcing eraseblock sized I/O
units. Does your CF-Card / USB-Stick do that ?
Just think about the 1GiB USB stick, which would present you 64KiB I/O
units instead of 2KiB ones.
Your signature is a nice intellectual signboard, but the ancient simple
rule of three just tells me, that you are off by factor 32.
tglx
-
