JFFS3 & performance

[Artem B. Bityuckiy]

> Extended attributes can be arbitrary, so they should go somewhere
> else.  Basically, have a pseudo-directory for each inode and treat the
> inodes inside that pseudo-directory as extended attributes.  Similar
> to reiser4.  Didn't Josh plan to work in this area?
Frankly speaking, do not really understand you. But do not care much,
did not think about xattr. This is another topic. And agree that xattrs
may be different, and what I proposed is not generic solution.

> What's so very special about NAND?  Either it's a useful storage
> medium (with slightly different details), or it's not.  If it is, you
> will never see this message.  If it's not, you shouldn't put any
> serious data on it anyway.  In both cases, you should never see this
> message.
> 
> If you do see the message, it means that you *thought* it would be a
> useful storage medium, but you're *wrong*.  Telling you that your
> conception of reality doesn't match reality itself is a service.
Did not want return to this :-)
We may print it for NAND too. If we provide method to clear our flag,
user may disable this.

> How about an rb_tree, sorted by the offset?  Just like the one in
> fs/jffs2/nodelist.h, hm? ;)
Yes, it is. But before you create fragtree:
1. You need dsize to create fragtree.
2. You have no structures which are sorted by offsets, so it is not easy
to obtain dsize.

That's problem. So, let us keep dsize alive :-)


On Thu, 2005-01-20 at 18:33 +0100, Jörn Engel wrote:
> On Thu, 20 January 2005 20:08:23 +0300, Artem B. Bityuckiy wrote:
> >
> > By the way, I'm not sure having times in our "inode flags node" is
> > reasonable. In this case we will need to update it very often and
> > possibly, will waste even more space (flag nodes have headers). If we
> > put only rarely changed data there, like UID and GID, we may save some
> > flash space... 
> 
> Makes some sense.  Needs more thinking...
> 
> > One more by the way, compression mode and whatever people implement in
> > xattr flags may go to that inode flags node.
> 
> Extended attributes can be arbitrary, so they should go somewhere
> else.  Basically, have a pseudo-directory for each inode and treat the
> inodes inside that pseudo-directory as extended attributes.  Similar
> to reiser4.  Didn't Josh plan to work in this area?
> 
> > And I still do not think that if we found bad block on NAND we should
> > print large warning every mount. For NOR, no doubts.
> 
> What's so very special about NAND?  Either it's a useful storage
> medium (with slightly different details), or it's not.  If it is, you
> will never see this message.  If it's not, you shouldn't put any
> serious data on it anyway.  In both cases, you should never see this
> message.
> 
> If you do see the message, it means that you *thought* it would be a
> useful storage medium, but you're *wrong*.  Telling you that your
> conception of reality doesn't match reality itself is a service.
> 
> > > Ouch!  Ok, looks like this one could stay.
> > > 
> > > Although...we do have the offset already.  So for the 4k case, it's
> > > pretty simple to build the fragtree as well, as there is just one node
> > > that could possibly be in the 4k range for it.
> > > 
> > > The remaining cases get quite a bit messier.  They remain the rare
> > > case, so it may still be worth the effort, if anyone cares enough to
> > > write the code.
> > > 
> > 
> > Anyway, nodes are not sorted on media. So to find the node with 
> > next offset we will need to do some search. This is time consuming. Or
> > we will need to keep nodes in offset-sorted list,
> 
> How about an rb_tree, sorted by the offset?  Just like the one in
> fs/jffs2/nodelist.h, hm? ;)
> 
> You're right, it's not sure whether this is actually a useful
> optimization.  But it's not trivial to dismiss either.
> 
> Jörn
>