NAND device for JFFS2?

NAND device for JFFS2?

[Ferenc Havasi]

Dear All,

Can anyone advice us any (not too expensive) hardware device to test 
JFFS2 on NAND under Linux. Actually we would like to speed up the mount 
time of JFFS2 and we need a hardware to try our ideas.

We had some IPAQ with Familiar Linux, but they have NOR flash. There is 
some IPAQ  (1900 and 2200) with NAND flash but there is no working Linux 
on them :-(

Regards,
Ferenc

Re: NAND device for JFFS2?

[David Woodhouse]

On Mon, 2004-06-14 at 11:58 +0200, Ferenc Havasi wrote:
> Dear All,
> 
> Can anyone advice us any (not too expensive) hardware device to test 
> JFFS2 on NAND under Linux. Actually we would like to speed up the mount 
> time of JFFS2 and we need a hardware to try our ideas.

SmartMedia connected off a parallel port? Or a DiskOnChip 2000 in one of
their ISA or PCI evaluation boards?

> We had some IPAQ with Familiar Linux, but they have NOR flash. There is 
> some IPAQ  (1900 and 2200) with NAND flash but there is no working Linux 
> on them :-(

Don't we have Linux on the h1900 yet?

-- 
dwmw2

Re: NAND device for JFFS2?

[Joshua Wise]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> > We had some IPAQ with Familiar Linux, but they have NOR flash. There is
> > some IPAQ  (1900 and 2200) with NAND flash but there is no working Linux
> > on them :-(
>
> Don't we have Linux on the h1900 yet?
I let the magic smoke out of the last one :(

I have a 2200 here that I'm working on a bootloader for now.

joshua

- -- 
Joshua Wise | www.joshuawise.com
GPG Key     | 0xEA80E0B3
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAzdOePn9tWOqA4LMRAh+DAJ95Q8MxdgfrnqBmtMnjLDHPQK1KmACgmDgP
UDU3/5uF7EzDhR27uxlFH3U=
=TYfW
-----END PGP SIGNATURE-----

(NAND) JFFS2 mount time

[Ferenc Havasi]

Hello Artem,

> Are your ideas about decreasing mount time secret? I'm also
> trying to optimize it a bit. Its interesting what way did you choose

No secret. (I hope your one is also no secret, so we may contiue this
conversation on this mailing list) I found some previos conversation about
it in the archives, too...

About our idea/plan: we would like to modify the mkfs and umount porcess
to store some extra information (inode_cache). At booting time it is
enough to read this information to serve the read requests, and the full
scan process can be done in the background. Write requestes should be
blocked until this background process finished. If I am right handeld
devices (but at least the Familiar distribution) uses RAM filesystem for
/tmp and /var, so the boot process hopefully does not require write
access.

Certainly, if this information cannot be found or not valid (there was no
umount) the original slow full scan method should be processed.

One possible idea to store this information can be to introduce new types
of node (with JFFS2_FEATURE_RWCOMPAT_DELETE bitmask). One type to store
the real information (inode_cache) and an other which is stored on the
first erase block and contains direct pointers to the previous kind of
nodes/its eraseblocks. (make it easy for the mount process to find them)

What are your ideas? Did you tried out them?

We did not tried this yet, but I hope it is feasable. (David?)

Regards,
Ferenc

Re: (NAND) JFFS2 mount time

[David Woodhouse]

On Tue, 2004-06-15 at 08:52 +0200, Ferenc Havasi wrote:
> About our idea/plan: we would like to modify the mkfs and umount porcess
> to store some extra information (inode_cache). 

I wasn't going to do it on umount. I was going to do it at the end of
each eraseblock. When we've almost filled an eraseblock we write a
summary to the end of it, containing all the information which we would
otherwise have to read from it during mount.

That's basically a list of the { inode#, physical_offset, length } for
each node in the eraseblock, and something about nlink. Note that
there's a lot of redundancy in the offsets and lengths so we can
contrive a storage method which is fairly efficient. 

Then at mount we look first at the _end_ of each eraseblock for such a
summary. If it exists, we read in the state from it. If not, we scan
that particular eraseblock the old way.

-- 
dwmw2

Re: (NAND) JFFS2 mount time

[Ferenc Havasi]

David Woodhouse wrote:

>I wasn't going to do it on umount. I was going to do it at the end of
>each eraseblock. When we've almost filled an eraseblock we write a
>summary to the end of it, containing all the information which we would
>otherwise have to read from it during mount.
>
>That's basically a list of the { inode#, physical_offset, length } for
>each node in the eraseblock, and something about nlink. Note that
>there's a lot of redundancy in the offsets and lengths so we can
>contrive a storage method which is fairly efficient. 
>
>Then at mount we look first at the _end_ of each eraseblock for such a
>summary. If it exists, we read in the state from it. If not, we scan
>that particular eraseblock the old way.
>  
>
Artem and our idea are very similar.

But I think your one is better. It's a little bit slower in mount time 
but much easier to implement (and also much more clean).

I think we'll start to implement it.

Regards,
Ferenc

Re: (NAND) JFFS2 mount time

[Artem B. Bityuckiy]

Hello Frank. Thanks for reply.

Ferenc Havasi wrote:
> About our idea/plan: we would like to modify the mkfs and umount porcess
> to store some extra information (inode_cache). At booting time it is
> enough to read this information to serve the read requests, and the full
> scan process can be done in the background. Write requestes should be
> blocked until this background process finished. If I am right handeld
> devices (but at least the Familiar distribution) uses RAM filesystem for
> /tmp and /var, so the boot process hopefully does not require write
> access.
> 
> Certainly, if this information cannot be found or not valid (there was no
> umount) the original slow full scan method should be processed.
> 
> One possible idea to store this information can be to introduce new types
> of node (with JFFS2_FEATURE_RWCOMPAT_DELETE bitmask). One type to store
> the real information (inode_cache) and an other which is stored on the
> first erase block and contains direct pointers to the previous kind of
> nodes/its eraseblocks. (make it easy for the mount process to find them)
> 
> What are your ideas? Did you tried out them?
> 
> We did not tried this yet, but I hope it is feasable. (David?)
> 
> Regards,
> Ferenc
> 
Very short description of my idea:

I thought about introducing special node type (say, raw_blkdescr) which 
should appear at the beginning of each block and describes some other 
block's layout. The process of writing will be like this: we write node 
on one block and simultaneously write it's description to some another 
free block.

When mounting, we just scan beginnings of flash blocks and construct 
inode_caches. After that we can read/write. Full scan goes in background.

I didn't try this too. More over, this is just an idea for now - I'm not 
even sure that such algorithm is feasible yet.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.