Re: [RFC] Volatile data device vor jffs2

On Sat, 2004-07-31 at 15:59 +0200, Jörn Engel wrote:
> With a ram based volatile device, there is danger of data loss, so
> garbage collection would have to be forced from time to time, similar
> to the current wbuf approach for nand.

I wouldn't do it like this -- why have a separate nvram device with
JFFS2 nodes in it, when we could just use the page cache and inode
cache. It's going to be _very_ hard to get fsync() et al right if we
implement our own caching.

The reason this hasn't been done is because it requires space
reservations, and that's not trivial. You have to ensure that you have
enough free flash space to make room for everything that's currently
outstanding in the cache. It shouldn't be _that_ hard though.

Doing this right should fix the problem you describe, of extremly
short-lived files hitting the medium when ideally they wouldn't ever get
written out. It would also help a lot with coalescing frequent short
writes to log files into larger nodes, and it would help us with
implementing shared writable mmap too.

--

-- 
dwmw2

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [RFC] Volatile data device vor jffs2

In message <20040802170824.GC26115 <at> wohnheim.fh-wedel.de> you wrote:
>
> Your approach doesn't always work for me because sometimes people care
> a lot about the last log entries.  They need to be inside a
> non-volatile medium, either nvram or flash.  Unless you want to move
> the page cache to nvram... ;)

Did you consider using oramfs? See http://pramfs.sourceforge.net/

Wolfgang Denk

--

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd <at> denx.de
Of all the things I've lost, I miss my mind the most.

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [RFC] Volatile data device vor jffs2

On Mon, 2 August 2004 19:14:57 +0200, Wolfgang Denk wrote:
> In message <20040802170824.GC26115 <at> wohnheim.fh-wedel.de> you wrote:
> >
> > Your approach doesn't always work for me because sometimes people care
> > a lot about the last log entries.  They need to be inside a
> > non-volatile medium, either nvram or flash.  Unless you want to move
> > the page cache to nvram... ;)
> 
> Did you consider using oramfs? See http://pramfs.sourceforge.net/

We already have something similar.  People have to sort their data and
send some to one fs, other to the other fs.  Prone to errors, static,
ugly code, etc.

Jffs2 would be able to do the sorting transparently.

Jörn

--

-- 
People will accept your ideas much more readily if you tell them
that Benjamin Franklin said it first.
-- unknown

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [RFC] Volatile data device vor jffs2

On Sun, 1 August 2004 13:33:01 +0100, David Woodhouse wrote:
> On Sat, 2004-07-31 at 15:59 +0200, Jörn Engel wrote:
> > With a ram based volatile device, there is danger of data loss, so
> > garbage collection would have to be forced from time to time, similar
> > to the current wbuf approach for nand.
> 
> I wouldn't do it like this -- why have a separate nvram device with
> JFFS2 nodes in it, when we could just use the page cache and inode
> cache. It's going to be _very_ hard to get fsync() et al right if we
> implement our own caching.

Your approach doesn't always work for me because sometimes people care
a lot about the last log entries.  They need to be inside a
non-volatile medium, either nvram or flash.  Unless you want to move
the page cache to nvram... ;)

Also, fsync can just do the same as sync.  If the helper device is
nvram, nothing at all.  If it's dram, flush it all to flash.

> The reason this hasn't been done is because it requires space
> reservations, and that's not trivial. You have to ensure that you have
> enough free flash space to make room for everything that's currently
> outstanding in the cache. It shouldn't be _that_ hard though.
>
> Doing this right should fix the problem you describe, of extremly
> short-lived files hitting the medium when ideally they wouldn't ever get
> written out. It would also help a lot with coalescing frequent short
> writes to log files into larger nodes, and it would help us with
> implementing shared writable mmap too.

DOCBoot and Millennium Plus

Hi,

I wanted to let you know that I have added support for the Diskonchip 
Millennium Plus to DOCBoot and also some minor enhancments:

1) added an option to build a BIOS extension
2) added an option to force specific DOC address

Currently is works only on Millennium Plus 16 MB devices. Support for 32 
MB is planned.

--

-- 
Kalev Lember

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

notice

Hello. I have a notice to the JFFS2 initialisation code.

It seems to me that it would be good to add the __init/__exit attributes 
to the jffs2_compressors_init/jffs2_compressors_exit (compt.c) functions.

--

-- 
Best regards, Artem B. Bityuckiy
Oktet Labs (St. Petersburg), Software Engineer.
+78124286709 (office) +79112449030 (mobile)
E-mail: dedekind <at> oktetlabs.ru, web: http://www.oktetlabs.ru

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [RFC] Volatile data device vor jffs2

On Sat, 31 Jul 2004 15:59:55 +0200, Jörn Engel  
<joern <at> wohnheim.fh-wedel.de> wrote:

> With a ram based volatile device, there is danger of data loss, so
> garbage collection would have to be forced from time to time, similar
> to the current wbuf approach for nand.

[-]

> Comments?

Well, it still needs to be flushed to something non-volatile at
some point.

You can vary the time between flushes. It depends on how valuable
that data is to you. With an approach such as this you are really
deciding how big of a window for data loss you are willing to put
up with.

The approach I took while doing this a couple of years ago was not
to erase blocks until absolutely necessary and then do all the
garbage collection/file system reorganisation once. This took time
to do though, was suitable for the device in question (a KVM), but
possibly not for a general filesystem.

Dermot.
--

______________________________________________________
Linux MTD discussion mailing list

Re: [RFC] Volatile data device vor jffs2

On Wed, 4 August 2004 09:55:41 +0100, Dermot McGahon wrote:
> 
> >Comments?
> 
> Well, it still needs to be flushed to something non-volatile at
> some point.

With a DRAM based device, yes.

> You can vary the time between flushes. It depends on how valuable
> that data is to you. With an approach such as this you are really
> deciding how big of a window for data loss you are willing to put
> up with.
> 
> The approach I took while doing this a couple of years ago was not
> to erase blocks until absolutely necessary and then do all the
> garbage collection/file system reorganisation once. This took time
> to do though, was suitable for the device in question (a KVM), but
> possibly not for a general filesystem.

That can be moved to a different thread, as already the case.  Except
for high-throughput write situations, it should be unnoticed by the
user.

Jörn

--

-- 
The grand essentials of happiness are: something to do, something to
love, and something to hope for.
-- Allan K. Chalmers

Re: ilookup() patch for linux-2.4.18

Don't use 2.4.18. It's almost inexcusable even to be using the current
2.4 kernel, which is 2.4.26 or 2.4.27. If you want proper NAND flash
support, just use 2.6.8.

--

-- 
dwmw2

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

ilookup() patch for linux-2.4.18

hello,
 i am working on smdk2410 platform ported with mizi linux-2.4.18.
we are using samsung nand flash for storing data on flash.
i am able to get older version jffs2 filesystem running on nand
flash with little nand support.i am trying to port latest
2004 july snapshot of MTD to my linux2.4.18 version.i am getting
undefined reference to ilookup() error when compiled.i saw the
ilookup patch for linux-2.4.23 which cannot be patched on
linux-2.4.18.please can you send me ilookup patch for linux-2.4.18.
i am attaching my inode.c source .
waiting for reply,

Regards,
Thanuja M

/*
 * linux/fs/inode.c
 *
 * (C) 1997 Linus Torvalds
 */

#include <linux/config.h>
#include <linux/fs.h>
#include <linux/string.h>
#include <linux/mm.h>
#include <linux/dcache.h>
#include <linux/init.h>
#include <linux/quotaops.h>