[mpich-discuss] ad_pvfs2_read bug in ADIOI_PVFS2_ReadStrided()

Wei-keng Liao wkliao at ece.northwestern.edu
Mon Jun 1 18:17:24 CDT 2009


Hi, Rob,

This situation has been handled at line 209 where frd_size is  
calculated.
n_filetypes will be increased by 1 so frd_size is kept > 0

In fact, this is very similar to our previous patch for data sieving
that makes sure the file pointer always points to a valid byte in the
fileview. But since pvfs2 driver is not updated with that patch, it
is still using the old approach and the old one can automatically
move the pointer to the right place in the NEXT I/O call.

I have revised my test code vector_view_read.c to include your test
pattern. It ran just fine with my patch. The only difference is the
pointer value, fd->fp_ind. But the I/O results are correct. So, it is
you call to pick one of two.

You can include the attached codes in ROMIO test repository.

Wei-keng

-------------- next part --------------
A non-text attachment was scrubbed...
Name: vector_view_read.c
Type: application/octet-stream
Size: 3464 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/mpich-discuss/attachments/20090601/331e9bf8/attachment.obj>
-------------- next part --------------




On Jun 1, 2009, at 5:36 PM, Rob Latham wrote:

> On Mon, Jun 01, 2009 at 05:26:32PM -0500, Wei-keng Liao wrote:
>> I tested your patch against mpich2-1.1.rc1 and
>> ran a few tests just fine.
>>
>> I can see you have added the calculation for updating the file  
>> pointer.
>> I wonder if it can be simplified by
>>   fd->fp_ind =
>> file_offsets[file_list_count-1]+file_lengths[file_list_count-1];
>
> True, this puts the file pointer at the end of the last byte written,
> but what if one past the last byte written points to an area not
> described by the file view?
>
> I would love to simplify this code, so hopefully you can tell me what
> I missed :>
>
> I was imagining a situation where the type looks like
> "|XXXX----XXXX----|"
>
> Let's say each X and - represents one integer
>
> If the request was to write 6 ints, then
> file_offsets[file_list_count-1]+file_lengths[file_list_count-1] is
> exactly right (that's your test case, after all) and would put the
> file pointer in the middle of the second batch of Xs.
>
> If the request was to write 8, though, then the file pointer would be
> set to an area not described by the file view, right?
>
> ==rob
>
> -- 
> Rob Latham
> Mathematics and Computer Science Division
> Argonne National Lab, IL USA
>



More information about the mpich-discuss mailing list