Tuesday, April 12, 2011

RFS: Efficient and Flexible Remote File Access for MPI-IO

8 comments:

  1. This comment has been removed by the author.

    ReplyDelete
  2. -Just a comment-In the paper we see that client-side caching can offer significant gains by reducing the cost of wide- area data movement, another paper which references to RFS takes this to a further step and suggests caching entire data-sets is not necessary and it suggests allowing the bootstrapping of dataset downloads by caching only a prefix of the dataset, while collective download facilitates efficient parallel patching of the missing suffix from an external data source. (Xiaosong Ma, et al. Coupling prefix caching and collective downloads for remote dataset access )

    ReplyDelete
  3. Why did the authors decide as one of their goals to focus on optimizing write-intensive workloads through latency hiding, rather than focus on optimizing services based on I/O patterns common to high-performance computation as done in the Global Access to Secondary Storage model ?

    ReplyDelete
  4. Did the authors introduce prefetching and caching yet to enhance ABT for RFS Reads? Did they evaluate the performance?

    ReplyDelete
  5. How is the ideal buffer size decided for RFS+ABT large-long, large-short & small-long file implementations?
    Saakshi

    ReplyDelete
  6. The important features of the paper seems to be the ability to specify noncontiguous accesses and passing hints to the implementation. How are the hints specified to the implementation?

    ReplyDelete
  7. In the paper it is said that manual staging is inefficient and cumbersome. But application staging though manual has more advantages and is more efficient than data staging. Still what are the issues faced in application staging due to which it is termed as inefficient?

    ReplyDelete
  8. Is there any particular reason for choosing C over other programming languages?

    ReplyDelete