[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New Release
<moved to jffs list>
> Would it be possible to get some idea of the current status of Jff2.
> What done?
The code in the 2.4.19 kernel, and on the jffs2-2_4-branch of CVS, should be
stable and reliable enough to use in production.
> What needs to be done?
> Whats wanted ?
See fs/jffs2/TODO in the CVS tree. The NAND support is mostly implemented,
and needs lots and lots of testing. Joakim has made some good optimisations
for speeding up the mount, and checkpointing will be helpful too if we can
manage to get that implemented at last.
In roughly increasing order of required competence...
Just installing the code on the trunk and giving good bug reports if/when
it fails is an extremely useful thing to do - don't underestimate the
benefit of that even if looking at the code makes you run away screaming.
(Thomas keeps complaining that my documentation - or lack of it - sucks :)
Fixing i_nlink on directories ought to be a fairly reasonable introduction
to the code, and quite simple. Track the number of child directories that
each directory has (you have a d_type in the dirent nodes so you don't need
to actually look at the children at all) and increase i_nlink for each one
in read_inode. I wouldn't increase the nlink in the jffs2_inode_cache
itself, just in the vfs_inode.
Implementing checkpointing would be good, and should dramatically improve
It needs a complete locking audit. The 2.5 kernel just pushed the BKL down
into the file systems, and I _think_ we can just remove it from JFFS2. I'm
not actually doing that till I'm sufficiently convinced that the locking's
Also, a lot of people would love you for ever if you can make some
guarantees about the amount of free space required to let GC continue, and
hence reduce the overly-conservative five blocks that it's keeping free at
> It looks like a lot of work has been done lately and I'd like to know
> how the core developers feel about the current status of the File
> system. Should I upgrade now ! or wait a bit.
As I said, the stable branch is stable. I'm valiantly resisting Joakim's
attempts to make me optimise it :)
The trunk is more fun - we do the fun stuff there. Even so, it should only
be likely to break on NAND flash - the NOR support should still be OK.
> Also this is off topic but is there a web site group dedicated to the
> "fastest" boot time for linux. I'm down around 2 min. I think its
> pretty good but I don't know.
More than 10 seconds is crap. You must be using one of those horrid sucky
PeeCee thingies I've heard so much about -- and without LinuxBIOS at that.
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to email@example.com