On Tue, 12 Sep 2000 [EMAIL PROTECTED] wrote:
> Put very simply, the question is whether readpage/writepage completion
> routines could be included as part of
> the inode/address space operations.
> The need for these arises in the case of async i/o for
> reading/writing pages, where the filesystem (or in the case I am
> considering, a filter filesystem stacked over it) needs to perform
> some filesystem specific post-processing on completion of the i/o.
> Doing a wait_on_page() inside a_ops->readpage() may not be
> appropriate, since it would force the operation to become synchronous.
> Think of what happens if the a_ops->readpage() is invoked during a
> read ahead , for example.
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).
> 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.
> There are further points to think about on how these ops if present
> should get invoked (e.g. in the typical block device async i/o end
> case, and then in a network filesystem case), but just to assess the
> need first of all, is there any other neat way in which we can achieve
> the same effect without introducing these ops ? Could I have
> overlooked something ? [To work properly in a layered filesystem
> implementation, the stacked layers should not need to know anything
> about each other - just following the VFS interface semantics must
> suffice ]
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.
-ben
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
