Messages in this thread | | | Date | Wed, 10 Apr 2002 18:12:11 -0400 | Subject | Re: [prepatch] address_space-based writeback | From | Jan Harkes <> |
| |
On Wed, Apr 10, 2002 at 12:16:26PM -0700, Andrew Morton wrote: > I believe that the object relationship you're describing is > that the inode->i_mapping points to the main address_space, > and the `host' field of both the main and private address_spaces > both point at the same inode? That the inode owns two > address_spaces?
Actually with Coda we've got 2 inodes that have an identical i_mapping. The Coda inode's i_mapping is set to point to the hosting inode's i_data. Hmm, I should probably set it to the i_mapping of the host inode that way I can run Coda over a Coda(-like) filesystem.
> That's OK. When a page is dirtied, the kernel will attach > that page to the private address_space's dirty pages list and > will attach the common inode to its superblock's dirty inodes list.
But Coda has 2 inodes, which one are you connecting to whose superblock. My guess is that it would be correct to add inode->i_mapping->host to inode->i_mapping->host->i_sb, which will be the underlying inode in Coda's case, but host isn't guaranteed to be an inode, it just happens to be an inode in all existing situations.
> > What's more, I wonder how well does your scheme work with ->i_mapping > > to a different inode's ->i_data (CODA et.al., file access to block devices). > > Presumably, those different inodes have a superblock? In that > case set_page_dirty will mark that inode dirty wrt its own > superblock. set_page_dirty() is currently an optional a_op, > but it's not obvious that there will be a need for that.
Coda's inodes don't have to get dirtied because we never write them out, although the associated dirty pages do need to hit the disk eventually :)
Jan
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |