Re: JFFS3 & performance

Jörn Engel
2005-01-21T12:44:02Z

On Thu, 20 January 2005 20:57:33 +0300, Artem B. Bityuckiy wrote:
>
> > > 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?
> 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.

Basically, there are two kinds of file attributes. First the old,
well-known and well-defined ones from original unix, see stat(2).
Those are part of the inode for any unix-style filesystem. Plus any
arbitraty other attributes, that people may wish for. Since those are
neither well-known nor well-defined, we shouldn't statically allocate
space for them in the inode.

But I fear that you were talking about something completely different.
In that case, the "xattr" put me on the wrong track.

> We may print it for NAND too. If we provide method to clear our flag,
> user may disable this.

Sure. I'm ok to confine this to PARANOID mode or make it otherwise
user-controllable. Not everyone will want it, so it has to be a
tunable.

> > 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 :-)

Still not convinced, but I'm too lazy to argue over four bytes.

Jörn

--
"Translations are and will always be problematic. They inflict violence
upon two languages." (translation from German)