Re: JFFS2 mount time
Ferenc Havasi <[email protected]> Thu, 21 Oct 2004 22:05:23 +0200
| Newsgroups | gmane.linux.drivers.mtd,gmane.linux.file-systems.jffs |
|---|---|
| Message-ID | <[email protected]> |
David Woodhouse wrote: > It's looking good, but the kernel really needs to be able to write these > summaries for _itself_ in order to give a real improvement over the long > term. If the file system has to be read-only we might as well be using > cramfs, and if the summary becomes obsolete over time we might as well > not bother in a lot of cases. Our plan for it: We would like to store some additional information in jeb struct: - a type information, where there this type can be INODE_ONLY and ANYTHING_OTHER. This information is easy to detect during mount time. - a predicted summary size (calculated dinamically). It will be used to decide when to generate the summary. Ceratinly only for INODE_ONLY erase blocks. If I am right every node allocation is done by jffs2_reserve_space(). We would like to modify it, and introduce a new interface for it called jffs2_reserve_space_for_inode() function. Every inode storing function (there is no too much I think) should call jffs2_reserve_space_for_inode() with some extra information (inode number...). jffs2_reserve_space() should use only ANYTHING_OTHER eraseblocks, as jffs2_reserve_space_for_inode() use only INODE_ONLY ones. If there is no free space in them it should use the usual technique to find a clean eraseblock and start to store the new node in it. The generating of summary is also the task of jffs2_reserve_space_for_inode(), if the new inode (+summary) is not fit in the erase block, it will generates summary. What do you think? Regards, Ferenc ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/