|On Wed, 13 Sep 2000, Erez Zadok wrote:
|> We may have to change the VFS if we find that's the only way to support
a
|> chain (or tree! think fan-out) of callbacks, but we won't know until we
try.
|It's a chain/tree only at the conceptual level. At the page level it
|would be just a "need to call this guy when I'm uptodate". It's up to the
|callback function to collect all the pages it needs and then propagate the
|callback up the stack.
|
|VFS (and, more importantly, buffer cache/page cache) hackery is definitely
|needed. Fortunately, it looks fairly clean. Basically all we need to do is
|have a callback function pointer accessible through struct page (probably
|as an address_space operation, I was wrong earlier on). Then each instance
|of the code that sets the page uptodate must be modified to also check if
|the callback pointer is NULL and call it if it isn't.
|
|Ion
**************
Thanks, Ion.
That sounds close to what I had in mind.
But one problem that I could see in terms of using this address space op
in a stackable fileystem is on the reverse stacking path needed during i/o
completion.
i.e. We want things to happen in the following sequence:
upper layer readpage
lower layer readpage
lower layer readpagecomplete
upper layer readpagecomplete
As you have rightly observed in your earlier mail, the lower layer must
not know anything about the layer above it, and we do need to think about
how to use this address space op to achieve stacking without violating this
requirement.
(BTW, regarding the converse, what I really meant to say but perhaps didn't
manage to express properly is that the layer on top should not need to know
anything about the internals of how the lower layer implements its
functionality - since we would like to be able to layer over any file
system
type, without needing to know which type it is.
The stacked layer might have access to the underlying layer's inode ptr,
ops
etc, and save them or use them as needed since those are explicitly visible
to VFS)
One option that I first thought of was that the upper layer could change
the
lower layer's completion op to point to the upper layer's readpagecomplete.
The upper layer readpagecomplete would invoke the lower layer's completion
op, and then perform its own completion processing. The only complication
is that
the upper layer's readpagecomplete would still be passed in the lower
layer's
inode/page and would hence need to devise some means of locating the
corresponding upper layer inode/page (and from that the original lower
layer's
completion op too).
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
