Hierarchical names are easier to resolve because there is an overriding order to the components of the name being resolved. This allows the implementation to partition information along the lines of the hierarchy, for example by storing all DNS names in the same domain or all files in same directory together. On the contrary, attributes are not inherently ordered, the storage plan and resolution algorithms need to be open to more possibilities.

Attribute based names are effective because they are descriptive without ordering constraints. When naming objects that can be described many ways, or along many axes, attribute-based names are very helpful.

5 points for each explanation. Give a little more room on these, because these are difficult concepts to quantify. The key point to note is that hierarchy imposes an ordering and that ordering can be exploited for performance, but may be limiting in some applications.

The big advantage is that real-time tracing of file system accesses is intrusive and somewhat difficult to implement, eliminating that removes run time performance impact of the system and simplifies it.

A big disadvantage is that the information recorded in the filesystem is less detailed. One cannot tell which process made the recorded access or detect access types that the filesystem does not record. As a result, false associations may be detected, or real connections overlooked.

5 points for each explanation. These are not exhaustive lists of possible advantages/disadvantages.

The key is how failures affect the ability of readers and writers to gather quorums. Each file must have at least a read quorum's worth of votes at functional representatives to allow reads to proceed. For writes the situation is more complex. A write requires a previous read to acquire the version number of the file that must be captured in the write quorum. Users will be unable to write a file if either quorum cannot be acquired.

It's also worth considering the possibility that a failure takes down all copies of a write before the write is propagated. There are cases where it is possible to hold a write quorum that only covers one physical system, e.g., when a write quorum is 1 or when a particular representative has enough votes to fulfill the write requirements. If a write is made to such a representative and that representative fails before the file changes can be propagates, inconsistencies can arise.

5 points for noting that reads cannot continue with out a read quorum worth of active votes and a write cannot proceed without a write quorum worth of votes being up. 3 points for noting that a write requires both, and 2 more for noting the single site failure possibility.

The administrator can change the TTLs over time. While the domain is known to be stable, the TTLs can be large, allowing a lot of caching. As the change time approaches, the admin can reduce the TTLs, reducing caching (and increasing server load), but making clients more responsive to change. After the changes have been made, the TTLs can be re-increased. Notice that the administrator does have to plan ahead. If the TTLs are not reduced far enough in advance that all the cached copies at clients have been discarded, old, inconsistent values may stay in the system.

7 points for the basic TTL adjusting mechanism. 3 more for making it clear that old data must be purged, and that only time and a change of TTL will do that.