internal:fast09-reviewing:comments28

==+== FAST '09 Paper Review Form

==-== Set the paper number and fill out lettered sections A through G.

==-== DO NOT CHANGE LINES THAT START WITH ”==+==”!

==+== RAJU MUST REPLACE THIS LINE BEFORE UPLOADING

==+== Begin Review

==+== Paper #28

==-== Replace '000000' with the actual paper number.

==+== Review Readiness

==-== Enter “Ready” here if the review is ready for others to see:

Ready

==+== A. Overall merit

==-== Enter a number from 1 to 5.

==-== Choices: 1. Reject

==-== 2. Weak reject

==-== 3. Weak accept

==-== 4. Accept

==-== 5. Strong accept

2. Weak reject

==+== B. Novelty

==-== Enter a number from 1 to 5.

==-== Choices: 1. Published before

==-== 2. Done before (not necessarily published)

==-== 3. Incremental improvement

==-== 4. New contribution

==-== 5. Surprisingly new contribution

3. Incremental improvement

==+== C. Longevity

==-== How important will this work be over time?

==-== Enter a number from 1 to 5.

==-== Choices: 1. Not important now or later

==-== 2. Low importance

==-== 3. Average importance

==-== 4. Important

==-== 5. Exciting

2. Low importance

==+== D. Reviewer expertise

==-== Enter a number from 1 to 4.

==-== Choices: 1. No familiarity

==-== 2. Some familiarity

==-== 3. Knowledgeable

==-== 4. Expert

3. Knowledgeable

==+== E. Paper summary

The authors propose a driver-based approach to cache and minimize the amount of writes issued to flash devices, this is accomplished by merging and padding I/O requests.

==+== F. Comments for author

1. Conceptual comments; these are comments including what you think was good / not-so-good / improvements related to the “importance of the problem” and the “overall solution approach”

The idea is very simple, and the authors need to provide further detail about key design decisions.

2. Detailed comments related to design decisions / implementation / evaluation.

In general the writing of the paper could be improved, since the paper is very implementation oriented which makes it complicated to understand how individual components work (e.g. it is not clear the role of many components of your filter driver) and their interactions. Perhaps if you focus more on the high level idea and avoid detailed explanations of the internal structures work the reader will get more from it.

Some terms used are never defined, what is an IoPacket?

Some important design details are not presented, how much time are I/O operations delayed by merging?

The experiments section should also be revised to include more experiments which illustrate the performance over different workloads (i.e not file coping), for instance iozone. They should also take into account the overhead introduced by your driver.

In sec 5.2, the experiments are not very well defined, are the writes done sequentially or not, if they are done sequentially then this will be the best case performance for your improvement but that does not say much about other workloads.

In sec 5.3, how is the time measured, is it application, processing or device time, further what are the overheads of your driver?

In sec 5.4, exactly what do those benchmarks do? This will help clarify both the goal and exactly what they evaluate.

In sec 5.5, this experiment shows that 64KB will work for the device used, but does not necessary imply the same size of cache will work best for all UFD since they typically have differ substantially in their architecture depending on model and manufacturer.