[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: JFFS2 Request For Testing.
On Thu, 22 Feb 2001, Jan Harkes wrote:
> I just looked at linux/fs/jffs/inode-v23.c and it looks like it really
> tries to avoid using the pagecache right now. As the file_write looks
> totally synchronous, a lot of my rambling is possibly not appropriate.
Thanks for looking. The jffs code in the (non-ac) 2.4 kernel doesn't use
the page cache for writes, you're correct. But later versions in CVS do,
and more to the point, the jffs2 code (also in CVS) does.
> In any case, I don't think you would ever need invalidate_inode_pages.
> It is used only by some network filesystems to improve consistency.
Indeed. But until I did so, I was hitting a BUG() in clear_inode:
Adding jffs2_file_release which calls invalidate_inode_pages() avoided
triggering that bug, but it's obviously a hack, which is why I drew
attention to it.
<snip useful explanation - thanks>
> I guess you get dirty pages, but there is nothing that can/will write
> them out. When dirty pages are about to be written they are locked (see
> mm/filemap.c:filemap_datasync) and queued, once they hit the disk, the
> underlying writer unlocks the pages, so for a synchronous write the
> queuing party simply waits for the locks to be released (filemap_datawait).
> So maybe truncate_inode_pages is appropriate in your case, especially
> when the file_write is still as synchronous as in jffs.
Hmmm. You're probably right here. Although I do all writes synchronously
in commit_write() and supposedly unlock the page afterwards, I'm probably
doing something wrong. Maybe the garbage collect code, which uses
read_cache_page() to read the page from which it's garbage collecting,
isn't properly releasing it.
> Sorry for all the rambling, I hope it turns out to be useful,
Should be. Thanks.
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to email@example.com