JFFS - ready for submission into 2.[34]?

JFFS - ready for submission into 2.[34]?

[David Woodhouse]

I'm fairly happy with the current state of the MTD code - my remaining
niggles are lack of certain functionality rather than stupidities in the
code, so I'm submitting it to Alan in the hope that he'll include it into
his 2.4.0-test1-ac kernels - after all, it's "only new drivers."

If I get away with that, it would be nice to get JFFS in too - Alex, is the 
code in our CVS ready for that or should we hold off for a while longer?



--
dwmw2




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

Re: JFFS - ready for submission into 2.[34]?

[Alexander Larsson]

On Thu, 1 Jun 2000, David Woodhouse wrote:

> I'm fairly happy with the current state of the MTD code - my remaining
> niggles are lack of certain functionality rather than stupidities in the
> code, so I'm submitting it to Alan in the hope that he'll include it into
> his 2.4.0-test1-ac kernels - after all, it's "only new drivers."
 Yes! Yes!
 
> If I get away with that, it would be nice to get JFFS in too - Alex, is the 
> code in our CVS ready for that or should we hold off for a while longer?

I will look at it tomorrow at work (Haven't had time before). All
functionallity should be implemented and work. I haven't done any larger
scale testing yet though, so it's definitely experimental. There is a bug
in the mkfs.jffs program though. It generates too big nodes (which the
jffs code can't handle) for files that are larger than 64k.

/ Alex




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

Re: JFFS - ready for submission into 2.[34]?

[David Woodhouse]

alex@cendio.se said:
>  I will look at it tomorrow at work (Haven't had time before). All
> functionallity should be implemented and work. I haven't done any
> larger scale testing yet though, so it's definitely experimental.

Fine. We all know how to get larger scale testing :)

> There is a bug in the mkfs.jffs program though. It generates too big
> nodes (which the jffs code can't handle) for files that are larger
> than 64k.

I saw the dicussion about this, and was wondering why mkfs.jffs actually 
populates the filesystem at all. Is it because it's more space-efficient to 
do it all at once than it would be to mkfs, mount and populate it?


--
dwmw2




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

Re: JFFS - ready for submission into 2.[34]?

[Alexander Larsson]

On Fri, 2 Jun 2000, David Woodhouse wrote:

> alex@cendio.se said:
> >  I will look at it tomorrow at work (Haven't had time before). All
> > functionallity should be implemented and work. I haven't done any
> > larger scale testing yet though, so it's definitely experimental.
> 
> Fine. We all know how to get larger scale testing :)
> 
> > There is a bug in the mkfs.jffs program though. It generates too big
> > nodes (which the jffs code can't handle) for files that are larger
> > than 64k.
> 
> I saw the dicussion about this, and was wondering why mkfs.jffs actually 
> populates the filesystem at all. Is it because it's more space-efficient to 
> do it all at once than it would be to mkfs, mount and populate it?

Possibly. But i suppose the real reason is that the current way would be
the way you normally use it in embedded systems (like those axis are
doing). You generate your root fs on the build machine, create a jffs
image and download it into the flash memory of the target system.

/ Alex




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

Re: JFFS - ready for submission into 2.[34]?

[David Woodhouse]

alex@cendio.se said:
> Possibly. But i suppose the real reason is that the current way would
> be the way you normally use it in embedded systems (like those axis
> are doing). You generate your root fs on the build machine, create a
> jffs image and download it into the flash memory of the target system.

Yeah, but it's still not imperative to create the image in one go from mkfs.

We create our Linux (and even NT) workstations by just taking a dump of the
filesystem after installation, and dd'ing that onto the target. That would
work just as well for JFFS.

Either way - once we get it working on NAND flash, and having to map round 
bad blocks, we're going to have difficulties with just dumping an image on
to the flash anyway. 

--
dwmw2




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

Re: JFFS - ready for submission into 2.[34]?

[Alexander Larsson]

On Fri, 2 Jun 2000, David Woodhouse wrote:

> 
> alex@cendio.se said:
> > Possibly. But i suppose the real reason is that the current way would
> > be the way you normally use it in embedded systems (like those axis
> > are doing). You generate your root fs on the build machine, create a
> > jffs image and download it into the flash memory of the target system.
> 
> Yeah, but it's still not imperative to create the image in one go from mkfs.
Actually I'm not sure jffs needs a special mkfs at all. An empty flash
should work just as well. It will just creates a root node at mount time.
 
> We create our Linux (and even NT) workstations by just taking a dump of the
> filesystem after installation, and dd'ing that onto the target. That would
> work just as well for JFFS.
That doesn't work well in a factory producing thousands of cameras a
week.
 
> Either way - once we get it working on NAND flash, and having to map round 
> bad blocks, we're going to have difficulties with just dumping an image on
> to the flash anyway. 

Well. The bad block remapping can certainly be problematic since the
journal won't be linear anymore. I suppose the lower layer mtd driver does
the remapping automatically?

/ Alex



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

Re: JFFS - ready for submission into 2.[34]?

[Finn Hakansson]

On Fri, 2 Jun 2000, Alexander Larsson wrote:

> On Fri, 2 Jun 2000, David Woodhouse wrote:
> 
> > 
> > alex@cendio.se said:
> > > Possibly. But i suppose the real reason is that the current way would
> > > be the way you normally use it in embedded systems (like those axis
> > > are doing). You generate your root fs on the build machine, create a
> > > jffs image and download it into the flash memory of the target system.
> > 
> > Yeah, but it's still not imperative to create the image in one go from mkfs.
> Actually I'm not sure jffs needs a special mkfs at all. An empty flash
> should work just as well. It will just creates a root node at mount time.

That's correct. One feature of JFFS is that one can mount a totally empty
device. The root node can thus be missing.


> [...]

> > Either way - once we get it working on NAND flash, and having to map round 
> > bad blocks, we're going to have difficulties with just dumping an image on
> > to the flash anyway. 
> 
> Well. The bad block remapping can certainly be problematic since the
> journal won't be linear anymore. I suppose the lower layer mtd driver does
> the remapping automatically?

I don't see why there should be more difficulties with NAND flashes. The
dumping of a file system image could be done in the same way as before and
besides, the bad block detection mechanism should be implemented for NOR
flashes as well. A bad-sector tracking mechanism is on our TODO list.

/Finn



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

Re: JFFS - ready for submission into 2.[34]?

[David Woodhouse]

alex@cendio.se said:
> > We create our Linux (and even NT) workstations by just taking a dump
> > of the filesystem after installation, and dd'ing that onto the target. That
> > would work just as well for JFFS. 

> That doesn't work well in a factory producing thousands of cameras a week.

You don't have to create the image over and over again - it's no harder to 
use 'dd' than it is to use 'mkfs', surely?

--
dwmw2




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

Re: JFFS - ready for submission into 2.[34]?

[Alexander Larsson]

On Fri, 2 Jun 2000, David Woodhouse wrote:

> 
> alex@cendio.se said:
> > > We create our Linux (and even NT) workstations by just taking a dump
> > > of the filesystem after installation, and dd'ing that onto the target. That
> > > would work just as well for JFFS. 
> 
> > That doesn't work well in a factory producing thousands of cameras a week.
> 
> You don't have to create the image over and over again - it's no harder to 
> use 'dd' than it is to use 'mkfs', surely?

The mkfs.jffs just creates a file that you copy to the flash. It doesn't
work directly on the flash-memory.

/ Alex




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

Re: JFFS - ready for submission into 2.[34]?

[Bjorn Wesen]

On Fri, 2 Jun 2000, David Woodhouse wrote:
> I saw the dicussion about this, and was wondering why mkfs.jffs actually 
> populates the filesystem at all. Is it because it's more space-efficient to 
> do it all at once than it would be to mkfs, mount and populate it?

It's because when you build an embedded product, you typically don't build
it on the target, so you have no way of mounting and populating it. You
should see mkfs.jffs more as a "filesystem cross compiler" than an mkfs
tool (as Finn wrote, there is no need for a "real" mkfs.jffs - an empty
flash will do).

So if you don't like the mkfs stage, you can skip it.

One drawback code-wise is that there is redundancy between code in
mkfs.jffs and in the filesystem itself of course. But the on-flash
node-structure of JFFS is so simple that mkfs.jffs is simple enough to
warrant it I think.

Regarding NAND-flashes and bad blocks - that works even with a pre-made
image. You just make sure the program that does the flashing knows to skip
the bad blocks. You obviously need to have a smaller image than the flash
size minus bad blocks as well :) 

-Bjorn




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

Re: JFFS - ready for submission into 2.[34]?

[Jason Gunthorpe]

On Tue, 6 Jun 2000, Bjorn Wesen wrote:

> It's because when you build an embedded product, you typically don't build
> it on the target, so you have no way of mounting and populating it. You
> should see mkfs.jffs more as a "filesystem cross compiler" than an mkfs
> tool (as Finn wrote, there is no need for a "real" mkfs.jffs - an empty
> flash will do).

Wow, that is really great. Right now with the FFS2 stuff I am using we
have to have a FFS2 module installed on the host to populate the file
system image, it kind of sucks in alot of ways.

> One drawback code-wise is that there is redundancy between code in
> mkfs.jffs and in the filesystem itself of course. But the on-flash
> node-structure of JFFS is so simple that mkfs.jffs is simple enough to
> warrant it I think.

Is the on flash structure documented? I need to write a simple read-only
driver for bootloaders. (see the boot stuff in MTD CVS, if it is still the
things I cooked up..)

There is a very good chance I am going to ditch FFS2 and just use JFFS for
all our products, I don't really like writing filesystem code and JFFS
sounds all round better than what MS came up wtih [FFS2 has inherent
consistency issues] :>

Thanks,
Jason



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

Re: JFFS - ready for submission into 2.[34]?

[Alexander Larsson]

On Thu, 1 Jun 2000, David Woodhouse wrote:

> I'm fairly happy with the current state of the MTD code - my remaining
> niggles are lack of certain functionality rather than stupidities in the
> code, so I'm submitting it to Alan in the hope that he'll include it into
> his 2.4.0-test1-ac kernels - after all, it's "only new drivers."

After some testing today i think its *not* ready for public consumption. I
managed to break one test where i truncated a file giving very strange
results, and al viros hashlist cleanup (which just replaced a home-grown
list with a list_head) made jffs freeze X for me (but it worked in the
console), which is something that simple patch shouldn't be able to do.
I've reverted that, but I want to look closer at it (no time today
though). 

But the filesystem does seem to work passably without you having to
implement half of VFS to test it, so I'd definitely would be interested in
a few people on the mtd-list testing it out.

Also, is anyone aware of a filesystem stress-test program i could try?

/ Alex





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

Re: JFFS - ready for submission into 2.[34]?

[Stephen Tweedie]

Hi,

On Fri, Jun 02, 2000 at 11:07:12AM +0200, Alexander Larsson wrote:
> 
> Also, is anyone aware of a filesystem stress-test program i could try?

"dbench" (it's on the samba site somewhere) is a good place to start.

--Stephen


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