Time for JFFS3?

[David Woodhouse]

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?

[Josh Boyer]

Post by David Woodhouse
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 ***@axis.com

[Ferenc Havasi]

Post by David Woodhouse
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 ***@axis.com

[David Woodhouse]

Post by Ferenc Havasi
If the name is JFFS3 than I aggree with Josh and a separated directory
should be better.

OK.

Post by Ferenc Havasi
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.

[David Woodhouse]

Post by Ferenc Havasi
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
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.

[Artem B. Bityuckiy]

Post by David Woodhouse
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.... :-(

Post by David Woodhouse

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 ***@axis.com

[David Woodhouse]

Post by Artem B. Bityuckiy

Post by David Woodhouse
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.... :-(

eCos has a 'synth' target which results in a Linux executable. It can
use 'flash' which is actually a file on the Linux file system. That's
how I did most of the work on JFFS2/eCos in fact.

[Ferenc Havasi]

Dear All,

Here is a patch which allows the developer to limit the created file
size. It can be usefull on embadded devices where there are users who
don't know too much about the system.

If the user uses too big files JFFS2 can run out of RAM easily - and
simply hangs the system (dd if=/dev/zero of=/mnt/flash bs=4K hangs the
system quickly) I know that the the memory requirements of JFFS2 depends
on not only the size of the opened file but I have no better idea - and
it solves a part of the problem.

This limitation can be understood by the user, and is not too dificult
to implement. (see the small patch I attached)

David, can I commit it? Or wait for JFFS3? When will it happen?

Regards,
Ferenc

[Artem B. Bityuckiy]

Post by Ferenc Havasi
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 :-)
) ?

Post by Ferenc Havasi
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
the body of a message to ***@axis.com

[David Woodhouse]

Post by David Woodhouse
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.

Alternatively, if we decide we don't want to make it mount old jffs2
images we could go a little further -- we could remove the mode,
ownership, size and times from the data node too. We only really need
one instance of those in the common case, and we can save 24 bytes from
every data node if we put those in a _separate_ node.