kofemann

DATA AND METADATA COHERENCE
       Some modern cluster file systems provide perfect cache coherence among their clients.  Perfect cache coherence among disparate NFS clients is expensive to achieve, especially on wide area networks.  As such, NFS settles for weaker cache coherence that satisfies the requirements of most file sharing types.

   Close-to-open cache consistency
       Typically file sharing is completely sequential.  First client A opens a file, writes something to it, then closes it.  Then client B opens the same file, and reads the changes.

       When an application opens a file stored on an NFS version 3 server, the NFS client checks that the file exists on the server and is permitted to the opener by sending a GETATTR or ACCESS request.  The NFS client sends these requests regardless of the freshness of the file's cached attributes.

       When the application closes the file, the NFS client writes back any pending changes to the file so that the next opener can view the changes.  This al

kofemann

# https://docs.docker.com/compose/yml/
# Each service defined in docker-compose.yml must specify exactly one of
# image or build. Other keys are optional, and are analogous to their
# docker run command-line counterparts.
#
# As with docker run, options specified in the Dockerfile (e.g., CMD,
# EXPOSE, VOLUME, ENV) are respected by default - you don't need to
# specify them again in docker-compose.yml.
#
service_name:

kofemann

Latency Comparison Numbers
--------------------------
CPU cycle                                     0.3 ns
L1 cache reference                            0.5 ns
Branch mispredict                             5   ns
L2 cache reference                            7   ns             14x L1 cache
Mutex lock/unlock                            25   ns
Main memory reference                       100   ns             20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy              3,000   ns
Send 1K bytes over 1 Gbps network        10,000   ns    0.01 ms