JFFS3 & performance
Artem B. Bityuckiy
dedekind at infradead.org
Thu Jan 20 11:31:13 EST 2005
Jörn Engel wrote:
> Doesn't work. Those are per inode, unless you want all files to have
> the same owner.
Surely. I thought you suggested to introduce new type of nodes which are
per-inode and contain inode flags and other information which we do not
want to copy to each inode node, like PID, GID and time stuff.
> What would work, on the other hand, is to seperate inodes and data
> nodes. PID, GID and all the other inode fields are needed only once,
> not for every chunk of data belonging to that inode.
>
>
> And while we're at it, some other fields from the inodes should be
> removed.
>
> jint32_t atime; /* Last access time. */
> jint32_t mtime; /* Last modification time. */
> jint32_t ctime; /* Change time. */
Absolutely correct :-)
> jint32_t dsize; /* Size of the node's data. (after
decompression) */
>
> In most cases, dsize will be 4k. So we can just uncompress into the
> page and ignore the flag. For the last page of a file, we can do the
> same, even though the dsize is different.
> In the remaining cases, we'd have to uncompress to a buffer of 4k (or
> more, if we go for 64k nodes someday) and memcpy.
Hmm. I assume you offer to remove this field at all? Not sure it is good
Idea.
When we build fragtree we should know how many bytes in nodes. We do not
want to
uncompress data to calculate this...
> Might be worth the effort, even if it's just 4 bytes.
>
> uint8_t usercompr; /* Compression algorithm requested by the user
*/
AFIK, this is uncompleted Ferenc Havsi's stuff. He was going to add
smart compressioning. This is just ignored now.
More information about the linux-mtd
mailing list