Perspectives on Optimistically Replicated, Peer-to-Peer Filing
Page, Guy, Heidemann, Ratner, Reiher, Goel, Kuenning, Popek
SP&E 1998

what happens when an app opens a file for reading?
  might be a local copy of the file
  or it might ask some other replica over the network
  too bad if replicas have different versions!

what happens when I write a file?
  what if two clients write a file simultaneously?
  what if a replica misses my update?

If I write a file, then read it, will I see what I wrote?
  what if I read from different replica than I wrote?

how do you find the replicas of a given volume?
  how do you even know you're accessing a particular volume?
  what does one of their graft points look like?

what kind of system are they building?
  Petal-like economic argument for file big centralized file servers?
  workgroup filesystem, like NFS for class cluster?
  to keep your laptop synced with your desktop?
  to support disconnected operation?
  help manage shared files for group software project?
  as a building block in distributed systems?
    e.g. highly-available back-end storage for on-line ordering system
  how big can their system get? users? file systems? geography?

can we state a consistency rule?
  i.e. do we know enough to write correct applications?

what specific properties do they claim?
  "single-copy availability"
  optimistic consistency
  reliably detects conflicting updates
  resolves most conflicts automatically
  single bad node can't prevent progress

why are directories special -- why not treat like files?
  and accept the newest directory as a unit?

what are all the conflicting updates that can occur to a directory?

directory reconciliation algorithm
  what's the problem?
    if we reconcile, and I'm missing a file, did I delete it?
    or did you just create it?
  why not just mark files "deleted"?
    when can I forget about deleted files?
  why not GC after everybody has heard about the delete?
    I could GC, then reconcile w/ you, but you have not GC'd,
    so I hear about a delete I don't know about, and start again.
  Why does the two-phase idea work?
    disambiguates "I've never heard of that delete."
  Hmm, a single bad node will prevent this from completing...

what's up with p. 161 global zero name count?
  why not just treat it as a new file?

* Evaluation:

What do we learn from Figures 2 and 3?

They argue that sharing between users is very rare? p. 170
  What can we conclude from this?

Does it make sense to mix optimistic replication with
  aggressive file-server-like propagation of updates?
  All the uncertainty of optimism
    (am I about to make a conflicting change?)
  All the overhead of a file-server
    (I broadcast all of my updates immediately).

If the real problem is access to just my own files from many clients,
  would we design the system this way?
  maybe
  gets backups right
  automatic connected/disconnected handling