Re: [PATCH] ext2fs and large stores (> 1.5G)

[Ognyan Kulev]

Neal H. Walfield wrote:
> In conclusion: let's use Mach's eviction scheme as much as possible.
> This means only setting up mappings on demand (i.e. nothing up front
> except for the super block and the group descriptor image); less
> accounting on our part; and invalidating mappings when pages are
> flushed to backing store in pager_write_page.

I like this approach too but how to know reliably when page is evicted?
pager_write_page is called when page is changed, but if it's not
changed, how to know when page is evicted?  I see that Mach's
memory_object_data_return is what should be used, but there is no
libpager interface to it.  libpager.c/data-return.c don't call
callback function.

> A side note: the entire mapping area can now be floating--not just the
> indirect area (except for the super block and the group_desc_image,
> however, each of these should not be more than a block or two).

My first thought was: "This will require locking and unlocking of
blocks everywhere".  Imagine the following scenario (if we have no
locking/unlocking and evicting pages removes mappings): The kernel
decides to evict a page and calls m_o_d_return.  Just before removing
the mapping another thread gets pointer to that page.  Now we return
back to removing of the mapping and after that the other thread
continues by reading a byte from the evicted page that is not mapped
anymore...

One possible solution is to read a byte from the page immediately
after obtaining pointer to it.  This will go to pager_read_page that
will see that there is no mapping there.  Before such "peek" we can
add to a special peek_list that we expect this pointer to point to
that disk block.  When pager_read_page sees that there's no mapping it
will check peek_list and will arrange the things as they should be.
So there's hope we can live without request/release pairs :-)

Regards
--
Ognyan Kulev <ogi@fmi.uni-sofia.bg>, "\"Programmer\""