==+== 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 #000000 ==-== Replace '000000' with the actual paper number. ==+== Review Readiness ==-== Enter “Ready” here if the review is ready for others to see: [Enter your choice here] ==+== A. Overall merit ==-== Enter a number from 1 to 5. ==-== Choices: 1. Reject ==-== 2. Weak reject ==-== 3. Weak accept ==-== 4. Accept ==-== 5. Strong accept 3 ==+== 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 4 ==+== 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 3 ==+== D. Reviewer expertise ==-== Enter a number from 1 to 4. ==-== Choices: 1. No familiarity ==-== 2. Some familiarity ==-== 3. Knowledgeable ==-== 4. Expert 3 ==+== E. Paper summary In this paper, the authors propose a technique for improving storage controller availability by performing micro-recovery in the presence of thread failures using a state space model that requires no modifications to legacy code. The authors implement their technique in a storage controller and demonstrate the effectiveness and efficiency of their approach through experimental evaluation. ==+== F. Comments for author The problem addressed is an important and the solution proposed appears novel from a non-expert standpoint. I should point out however, that the proposed approach seems generic and would seem to equally apply in domains other than storage. The paper can be improved quite a bit with a clearer motivation to the problem with examples and a more systematic exposition of the techniques. These are elaborated on next. It would have been easier for me to appreciate the context of this work if the authors presented some concrete examples of typical thread-level failures that occur in a storage controller, clarifyin the notions of the address-spaces of these threads and how thread failures can be contained so as to not bring down the entire system. Missing context made it harder to appreciate the concerns. Another complementary way for motivating the problem would be with an analysis of the probability of failure occurrences for the lock acquire operations mentioned in Table 2 when threads holding such locks fail. It seems an analysis of failure logs would reveal this information. The concept of recovery points is not well explained. What are valid recovery points? What process does the system use to choose these? The first paragraph on Pg 6 that is intended to address this is scant on these details. The motivation for the SRP decisions is unclear. Why should Ri(t) meet Ci on every element of Ci? similar motivation is required for the decisions 2 and 3 as well for the SRP. It is unclear how system state gets restored to the recovery point. It is not just the state of the shared structures but the rest of the thread context that needs to be restored as well. In general, the paper needs to more systematically walk through the process of what states are recorded and how, how recovery points are chosen, and for a specific failure point what restoration level looks like (use example here for illustration) and how recovery process would work and how the undo-log is used within this process.. Some detailed comments: In pg 3, the authors mention that "In Example-1, the system can tolerate diry and unrepeatable reads" but it seems that if the increment is made by a failed thread and decrement is not, then counter will never reach zero and thus background task will not get to run. Also, before simply aborting the background task, one must consider if the background task is idempotent or not. Table 1, TiE is better described as Thread i performing an externally visible event (rather than say it is thread completion). Pg 5, I believe, it would be more precise to specify DR condition as T1W->T1U->T2R->T1F , similariy for LU. "Leaked resources" seems a more descriptive term for what you call "Residual resources" Pg 5, why is T1R->T2W->T2E->T1F a CD? The other two seem easy to explain but more explanation is required for this third condition. In Section 3.1, Why doesnt CD figure in the recovery criterion? Define "starting point for recovery" formally. This was one of the hardest parts to understand. In pg 6, When you state "track the sequence of state changes within a single thread" what states are you referring to? It seems that Figure 5 is missing details. If level indicates dirty reads or lost updates, why should numActiveUsers be decremented by 1? When replacing old value, what if the value had incurred substantial read / update operations since the failed thread had last logged the value. Wouldnt restoring an ancient value lead to inconsistency? Section 4.3 does not need to be a subsection. The description on "Ensuring Recovery Success" is mostly motivation and not implementation and thus need to be moved elsewhere or removed. The "Lock Granularity" discussion is also unnecessary since majority of the readers will be well-versed with the benefits of fine-grained locking. What is the memory resource overhead for Log(Lock)? What are the data structures used to maintain thread information when it is being tracked? The system throughput drops with increasing the CPU cycles, can this be used when more cycles are necessary to track a shared data structure? Figure 6. Why are some of the throughput values better than baseline despite the fact that additional work is being done? Is it the resolution of the measurement that is a problem? How many trials were averaged? Why not be sure by examining the code when you state "We attribute this to the possibility of nested lock conditions in that particular code path, ..." Why are there two row entries for IO state with different numbers in Table 3? In 5.4.1, it would save the reader some trouble if you explicitly mention what locks you use. Also, cite what studies conclude "The observation that latency increases with queue depth...." In 5.5.2, it would be more clear if you were to show an example or expt of when a recovery point does not meet the recovery criteria. You should describe terms/abbreviations used clearly the first time they are introduced. (ACID, cache tracks, SLR, etc.) Conclusion: programmer also needs to define "recovery points" ?? who defines these? what are these micro-feedback based learning methods that you refer to? either elaborate or do not talk about it. Typos: Section 2.3: there by -> thereby Section 4.2: figure 5 -> Figure 5 Section 5.4.2 title: of tracking -> on tracking ==+== G. Comments for PC (hidden from authors) [Enter your comments here] ==+== End Review