Sam,
Looks great!
A few minor comments
- pvfs2-touch.c: leaks io_servers and layout.server_list.servers.
- instead of sizeof(PVFS_BMI_addr_t), perhaps we can have sizeof(*io_servers)?
- sys-create.sm: seems to leak  sm_p->u.create.layout.server_list.servers?
- I forget if these qhash_search(PINT_fsid_config_cache_table)
required a spinlock to serialize searches or if this a purely
client-side only code with no race conditions possible?
in pint_cached_config_*()
- ANy thoughts on how client-core/vfs apps should make use of the
additional layout information? Another Extended attributes on parent
directory perhaps?

Perhaps we could start versioning system interface function definitions
and have callers specify the version they are interested in?
something like callers have to #define PVFS_USE_VERSION before
including the pvfs.h header file.

#ifndef PVFS_USE_VERSION
#define PVFS_USE_VERSION  CURRENT_VER
#endif

#if PVFS_USE_VERSION  < CURRENT_VER
#define PVFS_sys_create(x,y,z) PVFS_sys_create_layout(x, y, z, NULL)
#endif

I am sure you guys would have thought of something along this, but
just wanted to doc it here in case :)
thanks,
Murali


On 6/20/07, Sam Lang <[EMAIL PROTECTED]> wrote:

On Jun 20, 2007, at 5:56 PM, Robert Latham wrote:

> On Wed, Jun 20, 2007 at 05:05:30PM -0500, Sam Lang wrote:
>> Let me know what you think.
>
> My only concern is keeping ROMIO in sync.  But what's one more
> autoconf macro?

Its a PITA, is what it is.  Rob and I talked about defining a new
PVFS_sys_create_layout function that would take a layout parameter,
leaving PVFS_sys_create untouched.  If ROMIO is going to be one of
the users of the layout structure, that may not make a lot of sense
though, and it seems messy.  With the latest PVFS FUSE port, maybe
there are more layers that have system interface deps, so we should
consider the potential impact there as well.

-sam

>
> ==rob
>
> --
> Rob Latham
> Mathematics and Computer Science Division    A215 0178 EA2D B059 8CDF
> Argonne National Lab, IL USA                 B29D F333 664A 4280 315B
>

_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers

_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers

Reply via email to