why MTD model ?

[Gregg C Levine]

Hello from Gregg C Levine
I agree David with you on all points, except one. Regarding the
reliability of PCMCIA-ATA drives. I have a bunch here right now, and
they are proving to be more reliable then the disk drives I keep buying
from the same shop. The fact that the manufacturer decided to
discontinue them because of size, is irrelevant. The fact that they came
with a FAT-12 file system, and a partition to match is also irrelevant.
-------------------
Gregg C Levine hansolofalcon at worldnet.att.net
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."  Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )



> -----Original Message-----
> From: linux-mtd-admin at lists.infradead.org [mailto:linux-mtd-
> admin at lists.infradead.org] On Behalf Of David Woodhouse
> Sent: Friday, June 14, 2002 8:22 AM
> To: Studying MTD
> Cc: linux-mtd
> Subject: Re: why MTD model ?
> 
> 
> studying_mtd at yahoo.com said:
> >  If some how i solve these issues :-
> > 1. sector size
> > 2. erase/write
> > 3. wear levelling
> 
> The core MTD API isn't there to solve those issues for you, only to
> represent the raw hardware -- and we have existing drivers for many
types of
> raw hardware.
> 
> Those issues are solved by whatever _uses_ the MTD devices -- and
there are
> a number of solutions already implemented in the MTD code base. The
most
> sensible way to put a file system on flash is to use a file system
> especially designed for that purpose -- such as JFFS2. However, for
legacy
> reasons we also have code which uses MTD devices to emulate hard
drives, as
> for some strange and inexplicable reason you seem to want.
> 
> In the days of DOS, it was difficult to add a real file system, so
instead
> people came up with a gross hack to make a flash device appear just
like a
> normal BIOS-supported disk drive.
> 
> They designed a pseudo-filesystem which emulated a hard drive, and
then
> provided a BIOS extension which overrode the INT 13h (Disk BIOS)
interrupt
> handler. Then people would just use a FAT file system on it under DOS
as if
> it was a normal hard drive.
> 
> When Windows started to gain its own 32-bit device drivers for hard
drives,
> the pseudo-filesystems that emulated hard drives were rewritten to run
> under Windows, but people were so used to the idea of a pseudo-fs
emulating
> a block device with a 'real' fs on top of that, that the opportunity
wasn't
> taken to make the whole thing sane just by having a proper file system
> directly on the flash.
> 
> The only half-sane reason for using a translation layer to emulate a
block
> device like this is on removable media -- if you need to be able to
remove
> the flash device from your Linux box and read it in a DOS or Windows
box.
> 
> If your flash isn't going to be removable, then you really don't want
to do
> it that way, for reasons which I've discussed at length quite
recently.
> 
> You should be using a proper file system directly on the flash. This
is not
> DOS, and you don't have to repeat DOS-based mistakes.
> 
> > Please let me know, which block device is closest to Flash memory :-
> > 1. Hard Disk 2. Floppy drive 3. PCMCIA memory card 4. Ramdisk 5. or
> > some other block device ?
> 
> Your question is very ambiguous. You might as well ask which tropical
fish
> is closest to flash memory. No block device is _similar_ to flash --
they are
> entirely different beasts.
> 
> I suppose the hard drive sitting on my desk with a pile of flash chips
on
> top of it is 'closest to Flash memory' in one way, but I suspect
that's not
> what you were asking.
> 
> If you mean which block device is most similar in performance and
general
> operation to a system which uses flash to emulate a block device, then
the
> answer would be PCMCIA-ATA or CompactFlash cards -- because they _are_
> using precisely such a translation layer internally. The only
difference is
> that they do it internally, in firmware (and generally quite
unreliably).
> 
> If you mean which block device driver code is most similar to the code
> you'd have to write to implement yet another translation layer, then
that
> would be something like the FTL or NFTL code -- they both use the
> underlying MTD drivers for the raw hardware, and perform their own
magic
> to present a block device implementation to Linux.
> 
> --
> dwmw2
> 
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/