• 07/21/09: BORG on Argonne storage system discussion
• 07/21/09: Medha defense practice talk
• 07/02/09: Medha Thesis Intro chapter discussion
• 02/19/09: Medha FAST practice talk
• 12/16/08: Camera-ready version discussion
• 11/13/08: Discussion of To-Do List

• Are we measuring the foreground overhead of reconfiguration? How?
• How are we changing the graphs in Figure 1 to make them smaller?

• Format paper according to FAST specifications.
  • Re-do EPS to include fonts.
• Modify Figure 1 so is more visible.
• Correct Figure 2.
• State why we use throughput instead of response time.
• Explain why we use 168x as acceleration factor.
• Explain why it is OK to run 1x while reconfiguration is running.
• Add a section of discussion where we address reviewers suggestions.
  • Events that trigger reconfiguration.
• State what “certain threshold” means in section 4.3.
• Change the name of OPT to be BOPT.
• Add: When the size of the map in memory is prohibited, the size of the OPT should be reduced.
• References:
  • Mac hfs' on-the-fly defragmentation.
  • Lumb et al. and Thereska et al.
• Explain the indirector behavior when the write region is full and a new write request is issued.
• Explain what values we take from blktrace.
• Simplify Figures 6, 7, 10 and 11 to make them more readable.
• Reduce the space used by referencing EXCES when possible.
• Add more detail of traces in section 2.
• Introduction in section 5.3.
• Sort references.

Dear Ken,

Here is a list of changes that we intend to make for the camera-ready version:

1. In the introduction, we will clarify the graphs in Figure 1 and possibly add additional graphs (space permitting) to clearly show details of workload characteristics.
2. In Section 4, we will clarify certain sections to address the following reviewer questions:
   • Explain what values of trace data do we collect from blktrace?
   • What does “certain threshold” mean in section 4.3?
   • How does the indirector behave when the write region is full and a new write request is issued?
3. We will explain the relevance of section 5.3 to BORG.
4. In the evaluation section we will justify:
   • Why we chose throughput as our metric versus response time.
   • Why we use 168X as acceleration factor in the non-reconfiguration phases and 1X in the reconfiguration phase.
   • Simplify Figures 6, 7, 10 and 11 to make them more readable.
5. Rename the acronym “OPT” to “BOPT” (for BORG OPtimized Target partition – other suggestions are very welcome!)
6. Add the missing references:
   • Mac hfs' on-the-fly defragmentation.
   • Lumb et al. and Thereska et al. work on freeblock scheduling
   • EXCES, our previous work on external-caching
7. Certain reviewer comments require more discussion. We plan to address these in an additional section titled “Discussion” to appear before the Conclusion section:
   • What events should trigger reconfiguration?
   • Alternative layout algorithms for the BOPT?
   • Is there a way for BORG to degrade performance gracefully?
8. Format the paper based on the FAST specifications
9. Address the typos, sort references

Please let us know if you have additional suggestions for improving the camera-ready version. We will address these and (other suggested changes from you, if any) and send you a version within the next 3-4 weeks.

If there is anything else you need from us, please let me know. I will be the contact author for this paper.

Luis' signature