On Fri, 2007-06-08 at 14:04 -0600, Andreas Dilger wrote:
> On Jun 08, 2007 14:04 -0400, Weikuan Yu wrote:
> > This is the MPICH2 patch I originally started as a base for some ROMIO
> > optimizations over Lustre. It should work fine for MPICH2-1.0.3 on
> > experimental systems. However, use it as your risk :)
> >
> > Given time, I will try to push out my optimizations after some cleanup. I
> > would very happy to hear feedbacks on what features people would need most
> > at the time.
>
> Would you object to me adding this patch to the lustre/contrib directory
> in the lustre distribution?
>
> Also, are there any plans to include this into an MPICH distribution? I
> think a lot of Lustre users would be happy to see that.
Please contact Dr. Robert Ross at [EMAIL PROTECTED] I believe that he
is the right person to tell you how that might be accomplished.
>
> Other notes - in about Lustre 1.6.2 it will be possible to use the FIEMAP
> ioctl to help in efficiently preallocating space in the file for the
> ADIO_FCNTL_SET_DISKSPACE fcntl. That will avoid the need to read the
> whole file, and instead just get a list of allocated and unallocated
> extents back.
For the benefit of Cray XT folks...
I was very interested in these patches that Mr. Yu has shared with us
all. Unfortunately, I can't see that they provide a benefit on a Cray XT
running Catamount.
There are no Lustre ioctl's of any kind implemented in liblustre. The
Lustre client driver takes them but just returns an error. Maybe my info
dated here? I admit it's been a coupe of months since I last looked at
this.
Asynch IO is supported by the interface but the lustre client actually
completes all operations at the time they are posted. Then again, for
the use-case on the XT, I'm not sure you would want to build the library
async IO. As noted in a comment in the patch, it can be slower than
sieving and, on the XT, I strongly suspect it would be even if asynch IO
worked.
The data sieve can be engaged via an MPI hint and executed at an extant,
higher, layer if I recall correctly.
Not to sound all negative... As I said, those comments are only meant
for us goofy XT folks. Excluding the XT, this looks like wonderful, very
worthwhile work. Kudos and much thanks to Mr. Yu.
>
>
>
> As an aside, it's too bad that the ADIO code is such a mess of #ifdefs.
> I suspect much of it could be cleaned up by having proper arch-specific
> macros/helper functions to wrap the internals.
>
> > +#ifdef HAVE_STATUS_SET_BYTES
> > + if (done && ((*request)->nbytes != -1))
> > + MPIR_Status_set_bytes(status, (*request)->datatype, (*request)->nbytes);
> > +#endif
>
> For example, this could be wrapped in a header and then each ADIO_* driver
> does not need to worry if HAVE_STATUS_SET_BYTES is set or not.
I do encourage you to talk about these patches and this idea with Dr.
Ross. He's asked me many times if there was a Lustre ADIO that he might
incorporate. I feel sure he will be interested in what you've done.
--Lee
>
>
> Cheers, Andreas
> --
> Andreas Dilger
> Principal Software Engineer
> Cluster File Systems, Inc.
>
> _______________________________________________
> Lustre-discuss mailing list
> [email protected]
> https://mail.clusterfs.com/mailman/listinfo/lustre-discuss
>
_______________________________________________
Lustre-discuss mailing list
[email protected]
https://mail.clusterfs.com/mailman/listinfo/lustre-discuss
