[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:

        if (inode->i_data.nrpages)

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 majordomo@xxxxxxx.com