Theodore Tso wrote:
On Wed, May 09, 2007 at 01:42:17PM +0530, Aneesh Kumar K.V wrote:
From: Aneesh Kumar K.V <aneesh.kumar@xxxxxxxxxxxxxxxxxx>
This I/O manager helps in stacking different I/O managers.
For example one can stack the undo I/O manager on top
of Unix I/O manager to achieve the undo functionality.
This is probably more generality than is strictly necessary; and the
place where the excess generality gets messy is the fact that you make
the stacking layer responsible for calling all of the io manager's
open routines (which is still a FIXME). So I would flush the stack_io
layer entirely.
Can't we address the FIXME by calling the respective close routine in
the failure case.
One thing i didn't like with the stack_io was, we will be opening the
device at each stacked I/O manager layer; which i also think is okey
provided we expect to use these I/O managers independently
What I would recommend as the fast and dirty approach. Basically, ape
the approach used by test_io layer _exactly_, except instead of using
a global variable test_io_backing_manager, you provide a function
which sets the static variable, undo_io_backing_manager. This
variable is used only by the subsequent call to the ->open method,
which just like test_io simply passes the name down to the backing
manager specified in the static variable. Then just make the undo_io
manager work the way test_io does, where does its thing, and then it
calls the appropriate function in its private->real io_channel.
Basically, make undo_io responsible for calling the next io_manager
down in the chain, This is workable because we don't need to
initialize the tdb file until we first try to write to the io_channel,
and ext2fs_open() only needs to do read operations, so we can set the
tdb filename via an optoin after ext2fs_open() returns.
One thing i was confused about was the usage of read_blk, write_blk etc
pointers in test_private_data. With respect to undo I/O manager do i
need to provide them ?. If we really need them, then i was thinking a
generic stacking layer as i send in the patches would be better. That
means any pluggable functionality that we achieve right now by setting
test_io_cb_read_blk etc will be implemented as a I/O manager that does
the particular task. Later we stack all these I/O manager to get the
full functionality.
-aneesh
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
