26 May, 2016

1 commit


07 Jun, 2014

1 commit


02 Jul, 2013

2 commits


02 May, 2013

1 commit

  • We don't need to use up entropy to choose an mds,
    so use prandom_u32() to get a pseudo-random number.

    Also, we don't need to choose a random mds if only
    one mds is available, so add special casing for the
    common case.

    Fixes http://tracker.ceph.com/issues/3579

    Signed-off-by: Sam Lang
    Reviewed-by: Greg Farnum
    Reviewed-by: Alex Elder

    Sam Lang
     

27 Feb, 2013

1 commit

  • Support (and require) the PGID64, PGPOOL3, and OSDENC protocol features.
    These have been present in ceph.git since v0.42, Feb 2012. Require these
    features to simplify support; nobody is running older userspace.

    Note that the new request and reply encoding is still not in place, so the new
    code is not yet functional.

    Signed-off-by: Sage Weil
    Reviewed-by: Alex Elder

    Sage Weil
     

21 Oct, 2010

1 commit

  • 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: Sage Weil

    Yehuda Sadeh
     

02 Aug, 2010

1 commit


22 Dec, 2009

1 commit


21 Nov, 2009

1 commit


04 Nov, 2009

1 commit


15 Oct, 2009

1 commit


08 Oct, 2009

1 commit


07 Oct, 2009

1 commit

  • 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: Sage Weil

    Sage Weil