Messages in this thread | | | Date | Wed, 10 Apr 2002 15:31:11 -0700 | From | Andrew Morton <> | Subject | Re: [prepatch] address_space-based writeback |
| |
Anton Altaparmakov wrote: > > At 22:44 10/04/02, Andrew Morton wrote: > >When a page is marked dirty, the path which is followed > >is page->mapping->host->i_sb. So in this case the page will > >be attached to its page->mapping.dirty_pages, and > >page->mapping->host will be attached to page->mapping->host->i_sb.s_dirty > > > >This is as it always was - I didn't change any of this. > > Um, NTFS uses address spaces for things where ->host is not an inode at all > so doing host->i_sb will give you god knows what but certainly not a super > block!
But it's a `struct inode *' :(
What happens when someone runs set_page_dirty against one of the address_space's pages? I guess that doesn't happen, because it would explode. Do these address_spaces not support writable mappings?
I like to think in terms of "top down" and "bottom up".
set_page_dirty is the core "bottom up" function which propagates dirtiness information from the bottom of the superblock/inode/page tree up to the top.
writeback is top-down. It goes from the superblock list down to pages.
The assumption about page->mapping->host being an inode only occurs in the bottom-up path, at set_page_dirty().
> As long as your patches don't break that is possible to have I am happy... > But from what you are saying above I have a bad feeling you are somehow > assuming that a mapping's host is an inode...
Well the default implementation of __set_page_dirty() will make that assumption. (It always has).
But the address_space may implement its own a_ops->set_page_dirty(page), so you can do whatever you need to do there, yes?
I currently have:
static inline int set_page_dirty(struct page *page) { if (page->mapping) { int (*spd)(struct page *, int reserve_page);
spd = page->mapping->a_ops->set_page_dirty; if (spd) return (*spd)(page, 1); } return __set_page_dirty_buffers(page, 1); }
Where __set_page_dirty_buffers() will dirty the buffers if they exist. And non-buffer_head-backed filesystems which use page->private MUST implement set_page_dirty().
The reserve_page stuff is for delayed-allocate, the priority and timing of which has been pushed waaay back by this. I'm keeping the reserve_page infrastructure around at present because of vague thoughts that it may be useful to fix the data-loss bug which occurs when a shared mapping of a sparse file has insufficient disk space to satisfy new page instantiations. Dunno yet.
(Sometime I need to go through and spell out all the new a_ops methods in all the filesystems, and take out the fall-through- to-default-handler stuff here, and in do_flushpage() and try_to_release_page() and others. But not now).
- - 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/
| |