headers
David Woodhouse | 18 Nov 15:38
Favicon

Time for JFFS3?

There's a lot of new stuff pending, and in the absence of a 2.7 kernel I
don't really want to destabilise the code too much. I think it's
probably time to take a branch and call it JFFS3, and dump all the new
and exciting stuff into it. JFFS2 would then be strictly bug fixes only.

	- Ferenc's summary support.
	- Artem's inode checkpoints and other stuff
	- xattr support
	- Splitting writes into nextblock_newstuff and nextblock_gc

It would probably still be able to mount existing JFFS2 images but you
probably wouldn't be able to go back.

Any objections?

--

-- 
dwmw2

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo <at> axis.com
Permalink | Reply | 9 comments |
headers
Josh Boyer | 18 Nov 16:56
Picon
Favicon

Re: Time for JFFS3?

On Thu, 2004-11-18 at 08:38, David Woodhouse wrote:
> There's a lot of new stuff pending, and in the absence of a 2.7 kernel I
> don't really want to destabilise the code too much. I think it's
> probably time to take a branch and call it JFFS3, and dump all the new
> and exciting stuff into it. JFFS2 would then be strictly bug fixes only.
> 
> 	- Ferenc's summary support.
> 	- Artem's inode checkpoints and other stuff
> 	- xattr support
> 	- Splitting writes into nextblock_newstuff and nextblock_gc
> 
> It would probably still be able to mount existing JFFS2 images but you
> probably wouldn't be able to go back.
> 
> Any objections?

Sounds good to me.  Like we discussed in IRC, I'd prefer a separate
jffs3 directory.  But it's your tree :).

josh

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo <at> axis.com
Permalink | Reply | 0 comments |
headers
Frank Buss | 18 Nov 20:41
Picon
Favicon

Linux 2.4 driver problem

Hi,

we are using the JFFS2 file system on an embedded system with an ARM PXA CPU
and a Linux 2.4.19 kernel. There are two JFFS2 partitions. Sometimes files
are destroyed, which result in a file error when trying to do a "ls" on the
directory. And sometimes there are kernel OOPS in filemap_nopage (see
http://www.frank-buss.de/tmp/error.txt). My questions:

- are there any bugfixes from the version in kernel 2.4.19 to the current
version?
- is it possible to back-port the current version to the 2.4.19 kernel?
- is it possible that the filemap_nopage errors are caused by the
filesystem?
- is it possible that two mounted JFFS2 partitions can cause problems?

Upgrading our system to kernel 2.6 is not possible, because the project is
already late and there are no other problems with the current kernel.

Regards,

Frank Buss

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo <at> axis.com
Permalink | Reply | 2 comments |
headers
Josh Boyer | 18 Nov 21:53
Picon
Favicon

Re: Linux 2.4 driver problem

On Thu, 2004-11-18 at 13:41, Frank Buss wrote:
> Hi,
> 
> we are using the JFFS2 file system on an embedded system with an ARM PXA CPU
> and a Linux 2.4.19 kernel. There are two JFFS2 partitions. Sometimes files
> are destroyed, which result in a file error when trying to do a "ls" on the
> directory. And sometimes there are kernel OOPS in filemap_nopage (see
> http://www.frank-buss.de/tmp/error.txt). My questions:
> 
> - are there any bugfixes from the version in kernel 2.4.19 to the current
> version?

Yes, a whole lot of them.

> - is it possible to back-port the current version to the 2.4.19 kernel?

Possibly, but no 2.4 kernels are supported really.  See:
http://linux-mtd.infradead.org/#kernelversions

You might be better off pulling JFFS2 from the latest 2.4 kernel and
using that.

> - is it possible that the filemap_nopage errors are caused by the
> filesystem?

Not sure.

> - is it possible that two mounted JFFS2 partitions can cause problems?

Again, not sure.  I don't remember any such problems, but it's been a
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Woodhouse | 19 Nov 00:16
Favicon

Re: Linux 2.4 driver problem

On Thu, 2004-11-18 at 20:41 +0100, Frank Buss wrote:
> Hi,
> 
> we are using the JFFS2 file system on an embedded system with an ARM PXA CPU
> and a Linux 2.4.19 kernel. There are two JFFS2 partitions. Sometimes files
> are destroyed, which result in a file error when trying to do a "ls" on the
> directory. And sometimes there are kernel OOPS in filemap_nopage (see
> http://www.frank-buss.de/tmp/error.txt). My questions:
> 
> - are there any bugfixes from the version in kernel 2.4.19 to the current
> version?

Just a few :)

> - is it possible to back-port the current version to the 2.4.19 kernel?

You'd do better to backport the old slow stable branch from the 2.4.27
kernel to 2.4.19. You'll only need to do a little bit of surgery on the
VFS for that.

> - is it possible that the filemap_nopage errors are caused by the
> filesystem?

It's possible, but I wouldn't claim I think it's likely. It's not a
failure mode which rings any bells and I don't see an obvious reason to
blame the file system for this -- it looks like the file system isn't
directly involved in that oops.

> - is it possible that two mounted JFFS2 partitions can cause problems?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ferenc Havasi | 19 Nov 10:00
Picon
Favicon

Re: Time for JFFS3?

David Woodhouse wrote:
> There's a lot of new stuff pending, and in the absence of a 2.7 kernel I
> don't really want to destabilise the code too much. I think it's
> probably time to take a branch and call it JFFS3, and dump all the new
> and exciting stuff into it. JFFS2 would then be strictly bug fixes only.
> 
> 	- Ferenc's summary support.
> 	- Artem's inode checkpoints and other stuff
> 	- xattr support
> 	- Splitting writes into nextblock_newstuff and nextblock_gc
> 
> It would probably still be able to mount existing JFFS2 images but you
> probably wouldn't be able to go back.
> 
> Any objections?

Sound good to me, too. But if it will be only a branch than we may 
should call it as JFFS2.5 or JFFS2++ :)

If the name is JFFS3 than I aggree with Josh and a separated directory 
should be better. But this name may suggest some more redesign/rewrite 
(maybe rewrite from scratch?).

Regards,
Ferenc

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo <at> axis.com
(Continue reading)

Permalink | Reply | 6 comments |
headers
David Woodhouse | 19 Nov 10:09
Favicon

Re: Time for JFFS3?

On Fri, 2004-11-19 at 10:00 +0100, Ferenc Havasi wrote:
> If the name is JFFS3 than I aggree with Josh and a separated directory 
> should be better.

OK.

>  But this name may suggest some more redesign/rewrite 
> (maybe rewrite from scratch?).

To me it implies a break in backwards-compatibility more than a rewrite.
Like ext2/ext3.

--

-- 
dwmw2

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo <at> axis.com
Permalink | Reply | 0 comments |
headers
David Woodhouse | 19 Nov 10:39
Favicon

Re: Time for JFFS3?

On Fri, 2004-11-19 at 09:41 +0000, Artem B. Bityuckiy wrote:
> > If the name is JFFS3 than I aggree with Josh and a separated directory
> > should be better. But this name may suggest some more redesign/rewrite
> > (maybe rewrite from scratch?).
> 
> IMHO the JFFS3 from scratch is not very good idea. My experience working 
> with JFFS2 shows to me that JFFS2 it is tricker that I always thought. 
> There are many many different aspects and it is very hard to keep them in 
> mind together. So, I believe, if we start from scratch, we may result in 
> filesystem that is worse then JFFS2 :-)
> 
> I think the best way is to start from JFFS2. Ten we may evolutionary 
> change it, trying to get better filesystem.

Rewriting it from scratch once was fun, and probably beneficial. I
wouldn't want to do it again yet until we have some dramatically better
ideas.

> How about to exclude the eCos support from JFFS3 (don't kill me please :-) 
> ) ?

I don't see why. It doesn't really hurt much, surely?

I'm perfectly happy to let it die if there's no interest from the eCos
side and it bitrots, but I wouldn't want to just decide to drop it.

> I just think about the possibility to change the format of some nodes. In 
> this case, if we mount JFFS2 image using JFFS3, we write JFFS3 nodes 
> there. As the result we have the image with mixed JFFS2 + JFFS3 nodes. How 
> to determine which file-system is this on the next mount? I believe, this
(Continue reading)

Permalink | Reply | 3 comments |
headers
Artem B. Bityuckiy | 19 Nov 10:41
Favicon

Re: Time for JFFS3?

> If the name is JFFS3 than I aggree with Josh and a separated directory
> should be better. But this name may suggest some more redesign/rewrite
> (maybe rewrite from scratch?).

IMHO the JFFS3 from scratch is not very good idea. My experience working 
with JFFS2 shows to me that JFFS2 it is tricker that I always thought. 
There are many many different aspects and it is very hard to keep them in 
mind together. So, I believe, if we start from scratch, we may result in 
filesystem that is worse then JFFS2 :-)

I think the best way is to start from JFFS2. Ten we may evolutionary 
change it, trying to get better filesystem.

How about to exclude the eCos support from JFFS3 (don't kill me please :-) 
) ?

> To me it implies a break in backwards-compatibility more than a rewrite.
> Like ext2/ext3.
I just think about the possibility to change the format of some nodes. In 
this case, if we mount JFFS2 image using JFFS3, we write JFFS3 nodes 
there. As the result we have the image with mixed JFFS2 + JFFS3 nodes. How 
to determine which file-system is this on the next mount? I believe, this 
is solvable, but I suspect this will not be easy...

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

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
(Continue reading)

Permalink | Reply | 4 comments |
headers
Artem B. Bityuckiy | 19 Nov 10:59
Favicon

Re: Time for JFFS3?

David Woodhouse wrote:
> I don't see why. It doesn't really hurt much, surely?
I don't know. I just do things for linux and don't know whether it will 
work on eCos.... :-(
> 
> 
>>I just think about the possibility to change the format of some nodes. 
In 
>>this case, if we mount JFFS2 image using JFFS3, we write JFFS3 nodes 
>>there. As the result we have the image with mixed JFFS2 + JFFS3 nodes. 
How 
>>to determine which file-system is this on the next mount? I believe, 
this 
>>is solvable, but I suspect this will not be easy...
> 
> 
> JFFS2 will refuse to mount the filesystem when it sees unknown nodes --
> just like ext2 will refuse to mount an uncleanly mounted ext3 file
> system.
But If we mount the mixed image in JFFS3, we may have to implement some 
tricks...

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

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo <at> axis.com
(Continue reading)

Permalink | Reply | 2 comments |

Gmane