Re: why MTD model ?

[David Woodhouse <dwmw2@infradead.org>]

studying_mtd@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 
file systems.

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 
directly. 

--
dwmw2