1. 21 11月, 2009 1 次提交
    • S
      ceph: fix debugfs entry, simplify fsid checks · 0743304d
      Sage Weil 提交于
      We may first learn our fsid from any of the mon, osd, or mds maps
      (whichever the monitor sends first).  Consolidate checks in a single
      helper.  Initialize the client debugfs entry then, since we need the
      fsid (and global_id) for the directory name.
      
      Also remove dead mount code.
      Signed-off-by: NSage Weil <sage@newdream.net>
      0743304d
  2. 19 11月, 2009 3 次提交
  3. 12 11月, 2009 1 次提交
  4. 11 11月, 2009 1 次提交
  5. 10 11月, 2009 1 次提交
    • S
      ceph: do not confuse stale and dead (unreconnected) caps · 685f9a5d
      Sage Weil 提交于
      We were using the cap_gen to track both stale caps (caps that timed out
      due to temporarily losing touch with the mds) and dead caps that did not
      reconnect after an MDS failure.  Introduce a recon_gen counter to track
      reconnections to restarted MDSs and kill dead caps based on that instead.
      
      Rename gen to cap_gen while we're at it to make it more clear which is
      which.
      Signed-off-by: NSage Weil <sage@newdream.net>
      685f9a5d
  6. 28 10月, 2009 1 次提交
  7. 16 10月, 2009 1 次提交
    • S
      ceph: flush dirty caps via the cap_dirty list · afcdaea3
      Sage Weil 提交于
      Previously we were flushing dirty caps by passing an extra flag
      when traversing the delayed caps list.  Besides being a bit ugly,
      that can also miss caps that are dirty but didn't result in a
      cap requeue: notably, mark_caps_dirty().
      
      Separate the flushing into a separate helper, and traverse the
      cap_dirty list.
      
      This also brings i_dirty_item in line with i_dirty_caps: we are
      on the list IFF caps != 0.  We carry an inode ref IFF
      dirty_caps|flushing_caps != 0.
      
      Lose the unused return value from __ceph_mark_caps_dirty().
      Signed-off-by: NSage Weil <sage@newdream.net>
      afcdaea3
  8. 15 10月, 2009 1 次提交
  9. 07 10月, 2009 1 次提交
    • S
      ceph: MDS client · 2f2dc053
      Sage Weil 提交于
      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: NSage Weil <sage@newdream.net>
      2f2dc053