public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Ollie Lho <ollie@sis.com.tw>
To: Patrick Higgins <phiggins@transzap.com>, mtd@infradead.org
Subject: Re: nftl and multi page read write support
Date: Tue, 01 Aug 2000 08:29:40 +0800	[thread overview]
Message-ID: <398619F3.6422BCEB@sis.com.tw> (raw)
In-Reply-To: Pine.LNX.4.21.0007311121400.32307-100000@phiggins.transzap.com

Patrick Higgins wrote:
> 
> On Mon, 31 Jul 2000, David Woodhouse wrote:
> 
> > rogelio@evoserve.com said:
> > > David - NFTL support is safe with the multipage read-write support. I
> > > have a system running on ext2 on nftl and it is stable.
> >
> > Cool - you mean not only does it _not_ break it, but it magically makes it
> > stable too?
> 
> Unless you've made some changes to NFTL (you were just verifying that your
> DoC2000 changes *didn't* break NFTL, right?) then NFTL still has some
> problems.  I'm having trouble finding time to look into the cause, but
> while I am able to read and write from a preexisting NFTL partition, I'm
> unable to make changes to it.  Using M-Systems' dformat utility from
> dosemu makes a single FAT partition.  When I try to use fdisk to toggle it
> to a Linux partition, things seem to go normally, but then when I run it
> again, the partition still shows up as FAT.  mke2fs also seems to complete
> successfully, but doesn't actually make changes.  However, mounting the
> FAT partition, touching a few files, unmounting, *rebooting*, and mounting
> again shows that the changes were permanent.  I have no idea what's
> wrong--but I assume, as David has pointed out, that something is probably
> wrong with the block device setup and/or partition table setup.  I'll look
> into it when I get the chance.
> 

One potential problem I just found and discussed with David. Currently the MTD
driver (doc2000.c doc2001.c) is hardcoded with Erase Block == 8kB but actually
very few nand flash chips in the M-System DoC 2000 are in 8kB block, most of 
them have 16kB erase block. This cause problem when you "folding" the "Virtual
Block Chain" in the NFTL layer (folding a vitrual block chain is a kind of
"garbage collection" in the NFTL that is the only case Erase is issued). Half of the block is lost since you think the
block is only 8kB but actually you have to
save 16kB of data.

I am currently reviewing the NFTL layer, there seems to be other problems too.
For example, try to use "nanddump" on a nftl_formatted/fdisked/mke2fsed DoC.
You will lost all your data (especially partition table) on the DoC.

Ollie


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

      parent reply	other threads:[~2000-08-01  0:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-07-31  7:07 nftl and multi page read write support Rogelio M. Serrano Jr.
2000-07-31  7:40 ` David Woodhouse
2000-07-31 17:32   ` Patrick Higgins
2000-07-31 20:06     ` Never mind Patrick Higgins
2000-08-01  0:29     ` Ollie Lho [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=398619F3.6422BCEB@sis.com.tw \
    --to=ollie@sis.com.tw \
    --cc=mtd@infradead.org \
    --cc=phiggins@transzap.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox