Zach Brown <zab@zabbo.net> wrote:
>
> so what we'd like most is the ability to invalidate a region of the file
> in an efficient go.
>
> void truncate_inode_pages(struct address_space * mapping, loff_t lstart,
> loff_t end)
>
> that sort of thing.
That's trivial in 2.5.
> this might not suck so bad if the page cache was an
> rbtree :)
Or a radix tree.
> but on the other hand, this doesn't solve another problem we have with
> opportunistic lock extents and sparse page cache populations. Ideally
> we'd like a FS specific pointer in struct page so we can associate pages
> in the cache with a lock,
In 2.5, page->buffers was abstracted out to page->private, and is available
to filesystems for functions such as this.
> but I can't imagine suggesting such a thing
> within earshot of wli.
wli doesn't have to run your kernel. If you want to add a pointer to the
pageframe, go add it. But I'd suggest that you do it with a view to
migrating it to page->private.
When you finally decide to do your development in a development kernel ;)
-
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/
This archive was generated by hypermail 2b29 : Thu May 15 2003 - 22:00:49 EST