Good Things:
    * This paper was extremely well written and clear. Good job.

Improvements:
    * LaTeX issue: quotes should be done as `` and '', not " and "
    * didn't give time frames and background info on every file system; that
        could have helped the reader.
    * several typos
    * didn't explain why this is a current issue and we should care, although 
        it is fairly obvious (to me)
    * rather than saying something *is* fault-tolerant, the paper should
        probably say that a system has features that aid fault-tolerance

======================================================================

This paper presents the issues associated with distributed file systems
followed by a survey of current and proposed distributed file systems.
While each example presented is succinctly summarized, the paper does little
to compare the examples; leaving the reader to draw conclusions.  With the
ever increasing reliance on networked computer systems, it is obvious that
distributed file system will continue to gain importance.  However beyond
providing clear motivation for an ideal distributed file system, this paper
does little to suggest future directions.

======================================================================

Overall, I think you did a good job of highlighting the important and
sometime conflicting issues of distributed file systems.  In general, you
showed the strengths and weakness of each system well. However, there were
a few concepts that were not clearly explained:  

1.  I didn't quite understand the weighted voting scheme.  It wasn't clear
who makes the votes and how this scheme increased availability and fault
tolerance.

2.  In the NFS section, it wasn't clear how XDR negatively affected
performance. 

3.  In the Echo section, you say that if a conflicting
request occurs, the server calls back the clients to revoke the tokens.  I
was wondering how the server decides when to revoke the tokens of other
clients.  It seems there would be security/performance hazard if a
client's request for a token would force all other conflicting clients to
give up their tokens immediately. 
	It might have been interesting to compare the overhead of fault
tolerance in Echo (logging of storage updates), xFS (parity storage), and
Harp (logging in volatile memory).  

4.  You said that xFS was a serverless network file system, which provides
high availability via redundant data, and that xFS uses RAID.  Later in
the Zebra section, you say that RAID technology uses parity instead of
redundant copies to guard against server failures.  This seemed
contradictory. Also, you referred to Zebra and RAID in the xFS section
before these terms were explained later in the Zebra section.  

You talked about how xFS provides scalability of control disk metadata and
cache consistency state, but you didn't describe how xFS keeps
consistency.  If xFS provides high availability through redundant data,
you should explain how it maintains consistency. 

======================================================================

This paper was well written and contained a great deal of interesting
material. It had a nice flow, which made it easy to read, and virtually
every idea presented was backed with adaquate support.

Because the introduction and conclusion emphasize conflicting needs and
tradeoffs, I felt there was a slight lack of both explicit comparisons
between systems and discussion of tradeoffs that each system faces with
it's particular design. For instance, tradeoffs weren't mentioned for
Andrew and Coda. There was a good discussion of the tradeoffs in the
introduction, but I would have mentioned the specific tradeoffs that every
system was forced to deal with.

Though a minor point, it would have been nice to have a brief description
of the paper's structure at the beginning so that the reader could have 
some idea what path the paper will take to achieve it's goal.

======================================================================

Your comments on the paper.  This is public comments that the authors
of the papers will see.  Provide feedback to improve their paper, etc.

Overall I liked this paper, especially the level of detail you went into
on each paper you reviewed.  The conflict between scalability and
security was a good, cohesive thread through your survey.  I would have
liked to see even more connections drawn between file systems, though. 
For example, xFS was created after Zebra and drew on some ideas from it,
but you present it earlier in the paper and don't tie them together.

======================================================================

The topic is not at all inappropriate or dead. However it doesn't
present something new or original. There is sufficient information
concerning specific file systems. There are only a few grammar
mistakes (luck of extended proofreading) and the font is not 12
point. The introduction is not well structured. It is too wide. It
could only refer to the ideal file system and then have a whole
different section about the problems that arise in the way to approach
the ideal file system. Also i beleive that the authors shouldn't refer
to the ideal file system with the phrase "would be" but they should
rather use the phrase "must be", cause our goal should be to have
someday an ideal file system that "must" meet all these requirements
that are presented in the introduction. In this paper there are 8
implementations presented, which i think it's too much. Also, there
isn't any comparison between the systems, we just get a raw
presentation of them and the conclusion is that we have to compromise
and make some trade offs.  Trade offs of what? There isn't any
suggestion of how to build an almost ideal file system. There aren't
any novel observations. The conclusion is poor, it prety much states
the difficulty to build an ideal file system.  This paper is more
likely a presentation of 8 different file systems and no specific
strategies of how to achieve an ideal file system are provided.

======================================================================