1. 01 Jul, 2013 2 commits
  2. 02 May, 2013 1 commit
  3. 26 Feb, 2013 1 commit
  4. 20 Oct, 2010 1 commit
    • Yehuda Sadeh's avatar
      ceph: factor out libceph from Ceph file system · 3d14c5d2
      Yehuda Sadeh authored
      This factors out protocol and low-level storage parts of ceph into a
      separate libceph module living in net/ceph and include/linux/ceph.  This
      is mostly a matter of moving files around.  However, a few key pieces
      of the interface change as well:
      
       - ceph_client becomes ceph_fs_client and ceph_client, where the latter
         captures the mon and osd clients, and the fs_client gets the mds client
         and file system specific pieces.
       - Mount option parsing and debugfs setup is correspondingly broken into
         two pieces.
       - The mon client gets a generic handler callback for otherwise unknown
         messages (mds map, in this case).
       - The basic supported/required feature bits can be expanded (and are by
         ceph_fs_client).
      
      No functional change, aside from some subtle error handling cases that got
      cleaned up in the refactoring process.
      Signed-off-by: default avatarSage Weil <sage@newdream.net>
      3d14c5d2
  5. 02 Aug, 2010 1 commit
  6. 22 Dec, 2009 1 commit
  7. 20 Nov, 2009 1 commit
  8. 03 Nov, 2009 1 commit
  9. 14 Oct, 2009 1 commit
  10. 07 Oct, 2009 1 commit
  11. 06 Oct, 2009 1 commit
    • Sage Weil's avatar
      ceph: MDS client · 2f2dc053
      Sage Weil authored
      The MDS (metadata server) client is responsible for submitting
      requests to the MDS cluster and parsing the response.  We decide which
      MDS to submit each request to based on cached information about the
      current partition of the directory hierarchy across the cluster.  A
      stateful session is opened with each MDS before we submit requests to
      it, and a mutex is used to control the ordering of messages within
      each session.
      
      An MDS request may generate two responses.  The first indicates the
      operation was a success and returns any result.  A second reply is
      sent when the operation commits to disk.  Note that locking on the MDS
      ensures that the results of updates are visible only to the updating
      client before the operation commits.  Requests are linked to the
      containing directory so that an fsync will wait for them to commit.
      
      If an MDS fails and/or recovers, we resubmit requests as needed.  We
      also reconnect existing capabilities to a recovering MDS to
      reestablish that shared session state.  Old dentry leases are
      invalidated.
      Signed-off-by: default avatarSage Weil <sage@newdream.net>
      2f2dc053