>There are a few different approaches to this that I've been playing with,
>and just implementing callbacks on pages is not flexible enough -- there
>can be multiple actions that need to be performed on the page when io is
>completed. My solution to this problem is to extend the waitqueue
>interface to allow callbacks to be used. That way any number of users can
>trigger async io on the page cache and have their request trigger message
>delivery without having to tie up tasks idly waiting for io to complete
>(needed on massive io servers).
This sounds interesting. Are you suggesting that in this case, one could
supply a callback function via add_wait_queue on the page lock and return?
Some questions that come to mind:
What is the intended semantics when multiple callbacks are registered ?
In what sequence do they get called ? (for a layered fs case, it may
be required in the reverse order of registration)
Is there a provision for registering an argument to be passed to the
callback function too ? (we need that to pass the correct inode ptr)
In the case I mentioned,there are situations where the callback needs to
be invoked with the page still locked (e.g if it needs to alter the
contents of the page just read-in).Is that achievable with your
approach ?
>> Ion, did you consider this during your implementation of cryptfs ?
There
>> you need to decrypt the contents of
>> the page loaded in by the underlying filesystem after the page read
i/o
>> is completed. The underlying
>> readpage() could return after initiating the i/o without waiting for it
to
>> complete, so currently you probably
>> just wait for the page lock to be released on i/o completion before
>> starting the decryption.
>For this case, doing it at the page level is wrong; it would be far
>better to have readpage trigger a brw_kiovec_async and then do the
>decryption on the kiobuf callback. Once decryption is done, make the page
>uptodate and do a wakeup on it.
>In the long term, using struct page as the io handle isn't as efficient as
>moving to kiovecs, which will make stacked filesystems *much* easier.
I'm not sure I quite understand this, though. The layered filesystem
wouldn't be initiating the i/o by itself - it is supposed to let the
underlying readpage routine do that, and that routine can choose to
perform the I/O in any manner that is suitable for the concerned
filesystem. So, when/where would it register the kiobuff callback ?
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
