1. 27 Oct, 2009 1 commit
  2. 22 Oct, 2009 1 commit
  3. 21 Oct, 2009 1 commit
  4. 19 Oct, 2009 2 commits
  5. 16 Oct, 2009 5 commits
  6. 14 Oct, 2009 3 commits
  7. 13 Oct, 2009 1 commit
  8. 12 Oct, 2009 2 commits
  9. 09 Oct, 2009 7 commits
  10. 08 Oct, 2009 1 commit
  11. 07 Oct, 2009 4 commits
  12. 06 Oct, 2009 12 commits
    • Sage Weil's avatar
      ceph: document shared files in README · e324b8f9
      Sage Weil authored
      Document files shared between kernel and user code trees.
      Signed-off-by: default avatarSage Weil <sage@newdream.net>
      e324b8f9
    • Sage Weil's avatar
      ceph: Kconfig, Makefile · 9030aaf9
      Sage Weil authored
      Kconfig options and Makefile.
      Signed-off-by: default avatarSage Weil <sage@newdream.net>
      9030aaf9
    • Sage Weil's avatar
      ceph: debugfs · 76aa844d
      Sage Weil authored
      Basic state information is available via /sys/kernel/debug/ceph,
      including instances of the client, fsids, current monitor, mds and osd
      maps, outstanding server requests, and hooks to adjust debug levels.
      Signed-off-by: default avatarSage Weil <sage@newdream.net>
      76aa844d
    • Sage Weil's avatar
      ceph: ioctls · 8f4e91de
      Sage Weil authored
      A few Ceph ioctls for getting and setting file layout (striping)
      parameters, and learning the identity and network address of the OSD a
      given region of a file is stored on.
      Signed-off-by: default avatarSage Weil <sage@newdream.net>
      8f4e91de
    • Sage Weil's avatar
      ceph: nfs re-export support · a8e63b7d
      Sage Weil authored
      Basic NFS re-export support is included.  This mostly works.  However,
      Ceph's MDS design precludes the ability to generate a (small)
      filehandle that will be valid forever, so this is of limited utility.
      Signed-off-by: default avatarSage Weil <sage@newdream.net>
      a8e63b7d
    • Sage Weil's avatar
      ceph: message pools · 8fc91fd8
      Sage Weil authored
      The msgpool is a basic mempool_t-like structure to preallocate
      messages we expect to receive over the wire.  This ensures we have the
      necessary memory preallocated to process replies to requests, or to
      process unsolicited messages from various servers.
      Signed-off-by: default avatarSage Weil <sage@newdream.net>
      8fc91fd8
    • Sage Weil's avatar
      ceph: messenger library · 31b8006e
      Sage Weil authored
      A generic message passing library is used to communicate with all
      other components in the Ceph file system.  The messenger library
      provides ordered, reliable delivery of messages between two nodes in
      the system.
      
      This implementation is based on TCP.
      Signed-off-by: default avatarSage Weil <sage@newdream.net>
      31b8006e
    • Sage Weil's avatar
      ceph: snapshot management · 963b61eb
      Sage Weil authored
      Ceph snapshots rely on client cooperation in determining which
      operations apply to which snapshots, and appropriately flushing
      snapshotted data and metadata back to the OSD and MDS clusters.
      Because snapshots apply to subtrees of the file hierarchy and can be
      created at any time, there is a fair bit of bookkeeping required to
      make this work.
      
      Portions of the hierarchy that belong to the same set of snapshots
      are described by a single 'snap realm.'  A 'snap context' describes
      the set of snapshots that exist for a given file or directory.
      Signed-off-by: default avatarSage Weil <sage@newdream.net>
      963b61eb
    • Sage Weil's avatar
      ceph: capability management · a8599bd8
      Sage Weil authored
      The Ceph metadata servers control client access to inode metadata and
      file data by issuing capabilities, granting clients permission to read
      and/or write both inode field and file data to OSDs (storage nodes).
      Each capability consists of a set of bits indicating which operations
      are allowed.
      
      If the client holds a *_SHARED cap, the client has a coherent value
      that can be safely read from the cached inode.
      
      In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
      is allowed to change inode attributes (e.g., file size, mtime), note
      its dirty state in the ceph_cap, and asynchronously flush that
      metadata change to the MDS.
      
      In the event of a conflicting operation (perhaps by another client),
      the MDS will revoke the conflicting client capabilities.
      
      In order for a client to cache an inode, it must hold a capability
      with at least one MDS server.  When inodes are released, release
      notifications are batched and periodically sent en masse to the MDS
      cluster to release server state.
      Signed-off-by: default avatarSage Weil <sage@newdream.net>
      a8599bd8
    • Sage Weil's avatar
      ceph: monitor client · ba75bb98
      Sage Weil authored
      The monitor cluster is responsible for managing cluster membership
      and state.  The monitor client handles what minimal interaction
      the Ceph client has with it: checking for updated versions of the
      MDS and OSD maps, getting statfs() information, and unmounting.
      Signed-off-by: default avatarSage Weil <sage@newdream.net>
      ba75bb98
    • Sage Weil's avatar
      ceph: CRUSH mapping algorithm · 5ecc0a0f
      Sage Weil authored
      CRUSH is a pseudorandom data distribution function designed to map
      inputs onto a dynamic hierarchy of devices, while minimizing the
      extent to which inputs are remapped when the devices are added or
      removed.  It includes some features that are specifically useful for
      storage, most notably the ability to map each input onto a set of N
      devices that are separated across administrator-defined failure
      domains.  CRUSH is used to distribute data across the cluster of Ceph
      storage nodes.
      
      More information about CRUSH can be found in this paper:
      
          http://www.ssrc.ucsc.edu/Papers/weil-sc06.pdfSigned-off-by: default avatarSage Weil <sage@newdream.net>
      5ecc0a0f
    • Sage Weil's avatar
      ceph: OSD client · f24e9980
      Sage Weil authored
      The OSD client is responsible for reading and writing data from/to the
      object storage pool.  This includes determining where objects are
      stored in the cluster, and ensuring that requests are retried or
      redirected in the event of a node failure or data migration.
      
      If an OSD does not respond before a timeout expires, keepalive
      messages are sent across the lossless, ordered communications channel
      to ensure that any break in the TCP is discovered.  If the session
      does reset, a reconnection is attempted and affected requests are
      resent (by the message transport layer).
      Signed-off-by: default avatarSage Weil <sage@newdream.net>
      f24e9980