why MTD model ?
dwmw2 at infradead.org
Fri Jun 14 03:54:59 EDT 2002
studying_mtd at yahoo.com said:
> you mean, it is possible.
> > but that is not a true representation of the
> > capabilities of the underlying
> > device.
> what you mean by "true representation of the capabilities" ?
> what i will miss, if i use memory flash device as block device and
> merge memory flash device with other block devices ?
Flash devices have large erase blocks. You cannot just treat them as a block
device with a sector size of 64KiB, etc. A flash device can have sectors
erased independently of write operations, can have write operations
performed independently of erases (e.g. JFFS2 does so just to clear one
extra 'valid' bit in existing nodes', can support writes to arbitrary byte
ranges, etc. The MTD API allows you to make use of those features.
The block device model does not offer a way to handle any of that. It only
allows you to make atomic updates of fixed-size sectors, which is not
something that flash devices are naturally capable of. To use flash as a
block device, you have to have some kind of 'translation layer' hack.
The simplest we have is the 'mtdblock' one, which on receiving a write
request simply reads the whole of the erase block which it landed in,
erases that block, then writes it all back out again with the offending
sector modified. That's obviously very unsafe, but it's OK for setting up
file systems which are going to be read-only in production.
Others are more complicated and safe w.r.t. power failure, essentially a
complete journalling file system in themselves just to emulate a block
device with small sectors. On top of which people put 'normal' journalling
Having a journalling file system atop a journalling file system sucks. We
do far better by exposing an API which represents the true functionality of
the underlying devices and designing a file system to make use of that
More information about the linux-mtd