Caching of reads
Good afternoon,
I've checked the documentation and list archives and I can't find anything which refers to my problem...
It seems as if reads from a JFFS2 file system are not being cached as we would expect, for instance this small script:
while true ; do
sleep 1
done
causes a read from the flash every time the sleep is executed. This is true even if the fs is mounted read only.
This is with a 2.4.14 kernel (and the JFFS2 therein), does anyone have any clue as to what might be going on?
Thanks IA,
Ian.
Signature · 20 lines
Ian Campbell Design Engineer Arcom Control Systems Ltd, Clifton Road, Cambridge CB1 7EA United Kingdom Tel: +44 (0)1223 411200 ext. 3204 E-Mail: [email protected] Web: http://www.arcomcontrols.com _____________________________________________________________________ The message in this transmission is sent in confidence for the attention of the addressee only and should not be disclosed to any other party. Unauthorised recipients are requested to preserve this confidentiality. Please advise the sender if the addressee is not resident at the receiving end. This message has been checked for all viruses by MessageLabs Virus Control Centre. Company registered in England No. 1608562. Registered Office: Unit 8, Clifton Road, Cambridge, CB1 7EA, United Kingdom, Tel: 01223 411200.
Quoted 7 lines · [email protected] said:
It seems as if reads from a JFFS2 file system are not being cached as
we would expect, for instance this small script:while true ; do sleep 1; done
causes a read from the flash every time the sleep is executed. This is true even if the fs is mounted read only.
Strange. JFFS2 doesn't do caching - that's supposed to be handle by the Linux VFS/VM. But set CONFIG_JFFS2_FS_DEBUG=1 and
echo 9 > /proc/sys/kernel/printk, then see what it's actually being asked to read each time.
--
dwmw2
Quoted 4 lines
Strange. JFFS2 doesn't do caching - that's supposed to be handle by the Linux VFS/VM. But set
CONFIG_JFFS2_FS_DEBUG=1and
echo 9 >/proc/sys/kernel/printk, then see what it's actually being asked to read each time.
Hi,
I've instrumented my kernel a bit and found that the reads are being caused by calls to jffs2_follow_link (in order to resolve the sym links for the libraries needed to load sleep)...
It's been pointed out to me that the jffs list might be a better place so I'll take this there...
Thanks,
Ian.
Signature · 20 lines
Ian Campbell Design Engineer Arcom Control Systems Ltd, Clifton Road, Cambridge CB1 7EA United Kingdom Tel: +44 (0)1223 411200 ext. 3204 E-Mail: [email protected] Web: http://www.arcomcontrols.com _____________________________________________________________________ The message in this transmission is sent in confidence for the attention of the addressee only and should not be disclosed to any other party. Unauthorised recipients are requested to preserve this confidentiality. Please advise the sender if the addressee is not resident at the receiving end. This message has been checked for all viruses by MessageLabs Virus Control Centre. Company registered in England No. 1608562. Registered Office: Unit 8, Clifton Road, Cambridge, CB1 7EA, United Kingdom, Tel: 01223 411200.
Quoted 6 lines · [email protected] said:
I've instrumented my kernel a bit and found that the reads are being
caused by calls tojffs2_follow_link(in order to resolve the sym links for the libraries needed to load sleep)...It's been pointed out to me that the jffs list might be a better place so I'll take this there...
Try this.
Index: include/linux/jffs2_fs_i.h
===================================================================
RCS file: /home/cvs/mtd/include/linux/jffs2_fs_i.h,v retrieving revision 1.8
linux/jffs2_fs_i.h +1 -0
@@ -44,6 +44,7 @@/* Some stuff we just have to keep in-core at all times, for each inode. */ struct jffs2_inode_cache *inocache; +unsigned char *symlink_target;/* Keep a pointer to the last physical node in the list. We don't use the doubly-linked lists because we don't want to increase the memory usage that much. This is simpler */
Index: fs/jffs2/readinode.c
===================================================================
RCS file: /home/cvs/mtd/fs/jffs2/readinode.c,v
retrieving revision 1.56
jffs2/readinode.c +3 -0
@@ -458,6 +458,9 @@D1 (printk (KERN_DEBUG "jffs2_clear_inode(): ino #%lu mode %o\n" , inode->i_ino, inode->i_mode)); +if (f->symlink_target) +kfree (f->symlink_target); + frags = f->fraglist; fds = f->dents;if (f->metadata) {
Index: fs/jffs2/symlink.c
===================================================================
RCS file: /home/cvs/mtd/fs/jffs2/symlink.c,v
retrieving revision 1.5
jffs2/symlink.c +22 -23
75 lines not on this page · raw message
--
dwmw2
Quoted 1 line
Try this.
It seems to do the trick!
Thanks very much for the exceedingly quick response!
Ian.
Signature · 20 lines
Ian Campbell Design Engineer Arcom Control Systems Ltd, Clifton Road, Cambridge CB1 7EA United Kingdom Tel: +44 (0)1223 411200 ext. 3204 E-Mail: [email protected] Web: http://www.arcomcontrols.com _____________________________________________________________________ The message in this transmission is sent in confidence for the attention of the addressee only and should not be disclosed to any other party. Unauthorised recipients are requested to preserve this confidentiality. Please advise the sender if the addressee is not resident at the receiving end. This message has been checked for all viruses by MessageLabs Virus Control Centre. Company registered in England No. 1608562. Registered Office: Unit 8, Clifton Road, Cambridge, CB1 7EA, United Kingdom, Tel: 01223 411200.
Quoted 2 lines · [email protected] said:
It seems to do the trick!
Thanks very much for the exceedingly quick response!
I'm not committing it. We want to do it the way ext2 does, with page_symlink_inode_operations and a readpage(). That way, we can drop the cached symlink target from memory when we can't just drop the whole inode.
--
dwmw2