[dcmf] [PATCH 1/1] Issue 4362: Honor the romio_ds_write and romio_ds_read hints.

[Bob Cernohous]

> > We have not tested, and will not attempt to test, PVFS.

Someone here commented that my testing statement sounded a bit harsh. 
Wasn't meant to be ;)  The original request specifically mentioned PVFS 
and I don't have PVFS, so I wanted to be clear that it hasn't been tested.

Rob Ross <rross at mcs.anl.gov> wrote on 02/08/2008 01:02:03 PM:
> 
> I'm still catching up, so I have some possibly stupid questions.
> - When you make a change such as the one below, how/when does it 
> appear on our BG/P?
> - How do we know that the patch is present (other than checking new 
> behavior)?

When I make a change here, of course it's available for anyone to patch, 
build, and run.

I guess you can assume I'm also putting it into our next release, but Joe 
Ratterman has some docmentation on releases, patches, processes etc.  I'm 
not sure what state it is in or how official it is yet.  We're still 
defining this.

This particular request (whomever it's from) came to me indirectly.  I 
guess I'd suggest the requestor ask the same channels for a particular 
release-level binary or whatever they really need.  I didn't get any more 
information than what I quoted in the patch.  It sounded like a good idea 
for open source/next release so I did it.

> To make things operate correctly on PVFS without the user needing to 
> specify a hint, we would like to use the results of statfs() at open 
> time to detect the PVFS volume. I think perhaps the minimum impact 
> change would be to set romio_ds_write to disable at open time when a 
> PVFS file system is detected. If we created a patch to accomplish 
> this, would your team be willing to integrate into BG/P releases?
 
> In the long run, we (ANL) would really like to eliminate all the lock/ 
> unlock calls in the PVFS case; they're unnecessary tree traffic that 
> can be avoided. Actually many of the locks aren't needed by GPFS file 
> systems either, so there's room for optimization on that side as well. 
> But that can be a separate discussion.
> 

Certainly you should submit patches into the open source and we'll 
consider them for BG/P releases.  That's part of Joe's documentation.

In this case ... are we talking about modifying BGL open()?  Or a higher 
level?   Isn't a full solution really to build ad_pvfs and select ad_pvfs 
vs ad_bgl at some higher level (with prefixes/hints/etc or statfs)?  I 
don't think we want ad_bgl trying to statfs() and select different file 
system behaviors at our level.   Show us a patch and we can comment 
better.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alcf.anl.gov/pipermail/dcmf/attachments/20080208/43ca8ac9/attachment.htm>