I am sorry to report that your paper, 'A Comparison of Logging and Clustering', was not accepted for presentation at the Summer 1994 USENIX conference. Although the committee thought the work was important and showed great promise, there was concern that it would not be complete in time for the final paper deadline. We encourage you to make the thorough measurements necessary to finish the analysis and resubmit to the next USENIX conference. If you feel the results cannot wait that long, you might consider Computing Systems, which has quick turnaround, or a brief presentation in ;login: followed by a full paper at the later conference. The following are excerpts from the reviews. This is clearly important follow-on work from the '93 Seltzer paper listed in the references and would be of significant interest. LFS and EFS should be defined. A reference to the '88 Winter USENIX paper by Peacock which described a clustered implementation of the System V Release 3 file system (which has shipped for a number of years as the SCO/Acer Fast File System) should be included. This paper was the admitted inspiration for McVoy and Kleiman's work. It's unclear whether there are any relevant references, but a number of other commercial implementations, including UNISYS and Wyse offerings, have used clustering at the disk driver level. Adjacent blocks are coalesced into single transfers by the disk driver to achieve cluster-like performance. There are quite a few holes in the paper, left with "this will be filled in later", which makes it hard to really judge its quality. It's difficult to tell if the work has enough technical merit to include because of all the missing sections. On the other hand, the identification of free list fragmentation as a problem in clustered file systems is accurate and is worth reporting. Reading between the lines in the tables which report the benchmark results, it appears likely that the difference in performance between EFS and LFS at small file sizes is due to the dominance of meta-data writes. It's clear that LFS will do better on meta-data writes than EFS. The issue of EFS free list fragmentation is worth investigating, particularly insofar as estimating how long it might take for the free list to degenerate. If the time is sufficiently long, infrequent reorganization of files in the background (as Veritas does to solve the free list degeneration problem) may take care of the problem, such that this disadvantage of clustering is eliminated. --- This work is too preliminary and largely speculative. Impact is not a verb. please do not mix tenses -- the present tense is usually the right one to use. Focused has one s. The reviewer is asked to take on faith that the authors will have results to report. I look forward to reading this paper when it is complete. At that time, perhaps you will explain why the column for EFS-write-b dips at 128 kb files; similarly the dips at 64 kb for EFS-write-c and at 128 kb for LFS- write c. Please graph the data to make it easier to assimilate. ---- The abstract is too brief. Why are the only "measurement" references in distributed systems? Rick Floyd at Duke measured Unix filesystem performance for his PhD I believe. This work is not finished yet. --- This work is of interest. The abstract is concise and to the point. Too many references to the Seltzer work. The table could perhaps be better displayed as several graphs instead of just raw numbers. Some key pieces are still missing, although promised. Some parts of the table that stood out to me weren't even mentioned (more on that below). Again, key pieces are still missing. I think the biggest problem I had while reading this is that there are too many references to the Seltzer paper. I understand and can appreciate that this is followup work to that and that is fine. However, this paper really needs to be standalone. You cannot assume that the reader is completely familiar with everything in the other paper. Most of this can be accomplished by simply adding 1 or 2 sentences summarizing the point from the Seltzer paper. For example in the Introduction, 2nd paragraph, 2nd sentence it says: "We have re-run all of the Seltzer benchmarks, and we have added...". I would suggest something like: "We have re-run all of the Seltzer benchmarks, which include raw bandwidth measurements, Andrew performance and transaction procession performance. We have also added..." Perhaps when discussing the actual benchmarks in Section 3, you could state all the Seltzer benchmarks up front instead of sprinkling them throughout each paragraph for each one. That would make the writing flow better as I found the large number of references distracting and caused reading it to become a bit choppy. The table is not a "nice" presentation of the data. I assume that it is there for review purposes and the authors intend to display it in a prettier graphical fashion in the final paper. If not, I ask they please consider doing that! One thing I noticed right away from the table is the consistent drop in EFS performance between 64K and 128K. For reads it drops by more than half and for writes(a)(b) it drops by a substantial percentage. Even though this paper focuses on LFS, I would like to see a bit explaining or speculating on why this is happening in EFS. Also, LFS writes suffer (to a much, much less degree) at the same boundary. ---- The extended abstract is missing some details of the implementations that are important to understanding the analysis. I assume that this will be fleshed out in the paper. Sec 1: "cautiously optimistic" What does this mean? Optimistic that LFS is fast enough to use? Optimistic that the performance will be better? Sec 3: What is the raw disk bandwidth for the tests? I assume you'll explain the modifications to EFS to reduce the number of synchronous writes. p2, very end: Will you specifically analyze the differences attributable to async writes and logging? Sec 3 table: I'm curious why the performance drops between 64Kb and 128Kb files for EFS reads, EFS and LFS writes (b), and LFS writes(c). Will there be discussion of these? Was the Andrew benchmark run with EFS or modified-few-sync-writes EFS? Sec 4: What, if any, are the differences between the EFS in SunOS and the BSD EFS? Are the differences relevant to your examination? Sec 4: For various disk sizes, how long does the cleaner take to run? Could I expect to run it in the wee hours of the morning? How many wee hours would I need? Sec 4 (end): will you explain what metadata writes are eliminated in LFS? ---- I am concerned with how far along the results are. I'd feel more comfortable if the results were more complete now.