[pnfs] Re-organizing the pNFS git tree

[Andy Adamson]

Hello eveyone.

I'd like to discuss this during tomorrow's pNFS status meeting.

We've worked hard on implementing the three IETF defined pNFS layout
types in Linux so that we can demonstrate interoperability and design
the generic portions of the pNFS client and server correctly. With this
experience we are now looking towards submission.

The submission process for the pNFS code into the kernel will start with
the file layout client and server, with the object and block code to
follow.

This means that we need to separate the pieces of the generic pNFS
client and server that are needed for the file layout type from those
that are not, with the goal of creating the simplest and least intrusive
base for submission.

I suggest that we organize the git tree to support a branch that is file
layout only, moving portions of the generic client and server not used
by the file layout into another branch inherited by the object and block
trees. For the sake of discussion, I call this branch the
object-block-generic-branch.
The file layout only branch will be the basis for kernel submission.

As a beginning, I have reviewed the client layoutdriver_io_operations
and layoutdriver_policy_operations noting each layout type's use.

There are currently 15 layoutdriver_io_operations.

The file layout driver uses 9:

struct layoutdriver_io_operations filelayout_io_operations = {
        .commit                  = filelayout_commit,
        .read_pagelist           = filelayout_read_pagelist,
        .write_pagelist          = filelayout_write_pagelist,
        .alloc_layout            = filelayout_alloc_layout,
        .free_layout             = filelayout_free_layout,
        .alloc_lseg              = filelayout_alloc_lseg,
        .free_lseg               = filelayout_free_lseg,
        .initialize_mountpoint   = filelayout_initialize_mountpoint,
        .uninitialize_mountpoint = filelayout_uninitialize_mountpoint,
};

The object layout driver uses 11, all 9 of the io operations used by the
file layout driver plus:

        .setup_layoutcommit      = panlayout_setup_layoutcommit,
        .cleanup_layoutcommit    = panlayout_cleanup_layoutcommit,

The block layout driver uses 14, all 11 of the io operations used by the
object layout driver plus:

        .write_begin                    = bl_write_begin,
        .write_end                      = bl_write_end,
        .new_request                    = bl_new_request,

The 15th io operation is not used, and should be removed.

        int (*ioctl) (struct pnfs_layout_type *, struct inode *, struct
file *, unsigned int, unsigned long);

This seems rather straight forward - the 9 I/O operations used by the
file layout driver are in the file layout only tree, the remaining 5
moved to the object-block-generic-branch.


The policy operations are different: given there is initially only one
layout type supported (the file layout), some of the policies can be
hard coded, and the operations that give a choice can be implemented in
the object-block-generic-branch.

There are currently 10 policy operations.

The file layout uses 7 policy operations

struct layoutdriver_policy_operations filelayout_policy_operations = {
        .get_stripesize        = filelayout_get_stripesize,
        .gather_across_stripes = filelayout_gather_across_stripes,
        .pg_test               = filelayout_pg_test,
        .layoutget_on_open     = filelayout_layoutget_on_open,
        .get_read_threshold    = filelayout_get_io_threshold,
        .get_write_threshold   = filelayout_get_io_threshold,
        .use_rpc_code          = filelayout_use_rpc_code,
};

The object layout uses 7 policy operations, 5 in common with the file
layout and two others: layoutret_on_setattr, get_blocksize

static struct layoutdriver_policy_operations panlayout_policy_operations
= {
        .get_stripesize        = panlayout_get_stripesize,
        .gather_across_stripes = panlayout_gather_across_stripes,
        .get_blocksize         = panlayout_get_blocksize,
        .get_read_threshold    = panlayout_get_io_threshold,
        .get_write_threshold   = panlayout_get_io_threshold,
        .layoutget_on_open     = panlayout_layoutget_on_open,
        .layoutret_on_setattr  = panlayout_layoutret_on_setattr,
};

The block layout uses 6 policy operations, 5 in common with the file
layout and do_flush.

static struct layoutdriver_policy_operations
blocklayout_policy_operations = {
        .get_stripesize                 = bl_get_stripesize,
        .get_read_threshold             = bl_get_io_threshold,
        .get_write_threshold            = bl_get_io_threshold,
        .pg_test                        = bl_pg_test,
        .do_flush                       = bl_do_flush,
};


The file layout only branch can end up with 4 policy operations with
gather_across_stripes hard coded to no, filelayout_layoutget_on_open
hard coded to yes, and use_rpc_code removed.

        .get_stripesize        = filelayout_get_stripesize,
        .pg_test               = filelayout_pg_test,
        .get_read_threshold    = filelayout_get_io_threshold,
        .get_write_threshold   = filelayout_get_io_threshold,

I have not looked at the generic server.

-->Andy