<br><font size=2 face="sans-serif">> > We have not tested, and will
not attempt to test, PVFS.</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><tt><font size=2>Rob Ross <rross@mcs.anl.gov> wrote on 02/08/2008
01:02:03 PM:<br>
> <br>
> I'm still catching up, so I have some possibly stupid questions.<br>
> - When you make a change such as the one below, how/when does it <br>
> appear on our BG/P?<br>
> - How do we know that the patch is present (other than checking new
<br>
> behavior)?<br>
</font></tt>
<br><tt><font size=2>When I make a change here, of course it's available
for anyone to patch, build, and run.</font></tt>
<br>
<br><tt><font size=2>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.</font></tt>
<br>
<br><tt><font size=2>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.</font></tt>
<br><tt><font size=2><br>
> To make things operate correctly on PVFS without the user needing
to <br>
> specify a hint, we would like to use the results of statfs() at open
<br>
> time to detect the PVFS volume. I think perhaps the minimum impact
<br>
> change would be to set romio_ds_write to disable at open time when
a <br>
> PVFS file system is detected. If we created a patch to accomplish
<br>
> this, would your team be willing to integrate into BG/P releases?<br>
<br>
> In the long run, we (ANL) would really like to eliminate all the lock/
<br>
> unlock calls in the PVFS case; they're unnecessary tree traffic that
<br>
> can be avoided. Actually many of the locks aren't needed by GPFS file
<br>
> systems either, so there's room for optimization on that side as well.
<br>
> But that can be a separate discussion.<br>
> <br>
</font></tt>
<br><tt><font size=2>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.</font></tt>
<br>
<br><tt><font size=2>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.</font></tt>
<br>