In article <[EMAIL PROTECTED]> you wrote:
> 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.
And yet I believe this is what we are currently doing, at least
in the 2.2 version. I'm not 100% sure about the 2.4 version, I
know we've made a few changes to remove some of the forced sync
calls. I don't think we fixed this, though.
> 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.
Basically, yes. The emphasis in our code has be so far on
correctness, rather than performance.
I remember looking at what it would take to remove the wait_on()
calls, but I don't remember the details. And with the almost
daily race to keep up with the VFS changes that were happening
at the time, this particular structural inefficiency was a just
minor annoyance.
> But in a read-ahead or async read situation, won't it be preferable to
> rather have an inode op (address space
> op, rather) that gets called when the read-in actually completes, so that
> the caller of readpage() doesn't have to
> be blocked till the i/o completes ?
It wouldn't help. What is needed, for proper stacking, is to call
readpage() and friends with a pointer to a callback function,
which would then be called back when the data becomes available.
Sort of an I/O completion function, if you want. This function
doesn't have to be an *_op at all.
Even better, since such a pointer would have to be stored with
the page, it would be easier to simply add the field to struct
page and then require that it be called (if not NULL) upon
completion, when the page is marked uptodate.
This is 2.5 material, though.
> [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 ]
No, the lower layer must not know anything about the layer above it,
the converse is not true. BTW, your idea of making this callback
function an *_op violates this requirement. :-)
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
