[PATCH] JFFS2 symlink cache

Artem B. Bityuckiy dedekind at infradead.org
Mon Feb 28 09:40:54 EST 2005


Hello,

here is newer version of the symlink caching patch.

The problem:
~~~~~~~~~~~

When the symlink inode is cached (e.g. iget() was called for it), JFFS2
does not cache the symlink's target in RAM. Instead, it reads it from
flash on every follow_link() inode method invocation (see symlink.c,
jffs2_follow_link()).

Most of the conceivable Linux systems stores dozens of symlinks in /lib
directory and access them very often (i.e., ld and libc library's links
are accessed almost on every program load). Hence, the patch might
improve performance and it should be especially sensible during system
boot.

Implementation:
~~~~~~~~~~~~~~

The patch is implemented very simple way. On iget(), the target path of
symlink is cached in RAM. On iput() it is it is freed(). In effect, any
follow_link() call is satisfied by the cached target path, without the
physical flash reading.

I 've also tweaked jffs2_symlink() slightly (dir.c) introducing new
targetlen variable instead of invoking strlen() several times.

Issues:
~~~~~~

Please, take a glimpse how I have implemented the jffs2_follow_link()
operation (symlink.c). Surely it safe to provide f->dents string to VFS?
I do down(&f->sem) there, but this is just paranoia and I think it isn't
really needed. Please, comment this.




 

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jffs2_symlink-03.diff
Type: text/x-patch
Size: 4636 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20050228/d6c70df9/attachment.bin 


More information about the linux-mtd mailing list