Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > Not sure its a good idea to overload page_has_private() with an > overloadable page-flag. What if some future FS wants to use > PG_owner_priv_2 for other purposes? All that it means is that releasepage() and co will get called if a page is to be released or invalidated that has that bit set. I think that's something a future FS could probably live with. However, I do have to trigger a call to releasepage() and co *somehow*. > Obviously filesystems cannot use these two page-flags if they want to be > compatible with FS-cache, but need all filesystems be? What do you mean? That's why I went for the PG_owner_priv_* approach rather than just naming the bits unto FS-Cache directly. > (also, ouch! - 2 pageflags) Yeah. The consequence of having things asynchronous is that you have to find signalling mechanisms to synchronise around the asynchronicity:-/ Furthermore, it occurs to me that I can't use PG_private or page->private to store this information because I want to make isofs use caching, and those two pieces of information are owned by the buffering code. David - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
