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
02 Aug, 2010
1 commit
-
Signed-off-by: Sage Weil
22 Dec, 2009
1 commit
-
Also, print fsid using standard format, NOT hex dump.
Signed-off-by: Sage Weil
21 Nov, 2009
1 commit
-
The mds map now uses the global_id as the 'key' (instead of the addr,
which was a poor choice).This is protocol change.
Signed-off-by: Sage Weil
04 Nov, 2009
1 commit
-
We exchange struct ceph_entity_addr over the wire and store it on disk.
The sockaddr_storage.ss_family field, however, is host endianness. So,
fix ss_family endianness to big endian when sending/receiving over the
wire.Signed-off-by: Sage Weil
15 Oct, 2009
1 commit
-
This avoids the fugly pass by reference and makes the code a bit easier
to read.Signed-off-by: Sage Weil
08 Oct, 2009
1 commit
-
A misplaced sizeof() around namelen was throwing things off.
Signed-off-by: Sage Weil
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