- 21 11月, 2009 1 次提交
-
-
由 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>
-
- 19 11月, 2009 3 次提交
-
-
由 Sage Weil 提交于
When we open a monitor session, we send an initial AUTH message listing the auth protocols we support, our entity name, and (possibly) a previously assigned global_id. The monitor chooses a protocol and responds with an initial message. Initially implement AUTH_NONE, a dummy protocol that provides no security, but works within the new framework. It generates 'authorizers' that are used when connecting to (mds, osd) services that simply state our entity name and global_id. This is a wire protocol change. Signed-off-by: NSage Weil <sage@newdream.net>
-
由 Sage Weil 提交于
Unwind initializing if we get ENOMEM during client initialization. Signed-off-by: NSage Weil <sage@newdream.net>
-
由 Sage Weil 提交于
We want to ceph_con_close when we're done with the connection, before the ref count reaches 0. Once it does, do not call ceph_con_shutdown, as that takes the con mutex and may sleep, and besides that is unnecessary. Signed-off-by: NSage Weil <sage@newdream.net>
-
- 12 11月, 2009 1 次提交
-
-
由 Sage Weil 提交于
This helps the user know what's going on during the (involved) reconnect process. They already see when the mds fails and reconnect starts. Signed-off-by: NSage Weil <sage@newdream.net>
-
- 11 11月, 2009 1 次提交
-
-
由 Sage Weil 提交于
We don't get an explicit affirmative confirmation that our caps reconnect, nor do we necessarily want to pay that cost. So, take all this code out for now. Signed-off-by: NSage Weil <sage@newdream.net>
-
- 10 11月, 2009 1 次提交
-
-
由 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>
-
- 28 10月, 2009 1 次提交
-
-
由 Sage Weil 提交于
This simplifies much of the error handling during mount. It also means that we have the mount args before client creation, and we can initialize based on those options. Signed-off-by: NSage Weil <sage@newdream.net>
-
- 16 10月, 2009 1 次提交
-
-
由 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>
-
- 15 10月, 2009 1 次提交
-
-
由 Sage Weil 提交于
This avoids the fugly pass by reference and makes the code a bit easier to read. Signed-off-by: NSage Weil <sage@newdream.net>
-
- 07 10月, 2009 1 次提交
-
-
由 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>
-