RepoMirrors/ceph
1
0
Fork 0
mirror of https://github.com/ceph/ceph synced 2025-03-11 02:39:05 +00:00
Code Issues Packages Projects Releases Wiki Activity
44,325 Commits 219 Branches 396 Tags 1.4 GiB
d65372162b
Commit Graph

15 Commits

Author SHA1 Message Date
John Spray
7e2e3bb505 mds: big MDS refactor stage 2: encapsulation 
Encapsulate MDSRank in MDS instead of inheriting from
it.

Signed-off-by: John Spray <john.spray@redhat.com>
 2015-07-28 09:05:08 +01:00
John Spray
f93bf3853f mds: typedefs for rank and gid in MDSMap 
Make it clearer what these numbers are where they appear.

Signed-off-by: John Spray <john.spray@redhat.com>
 2014-10-08 11:58:18 +01:00
John Spray
4f3b8032df mds: Switch to new context types 
Signed-off-by: John Spray <john.spray@redhat.com>
 2014-08-25 01:34:17 +01:00
Yan, Zheng
93ab1edd10 mds: don't roll back prepared table updates 
When table server is recovering, it re-sends 'agree' messages for
prepared table updates. It is possible table client receives an
'agree' messages before it commits the corresponding update. Don't
send 'rollback' message back to the server in this case.

Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
Reviewed-by: Greg Farnum <greg@inktank.com>
 2013-04-01 09:26:24 -07:00
Yan, Zheng
12e7c3d171 mds: avoid sending duplicated table prepare/commit 
This patch makes table client defer sending table prepare/commit messages
until receiving table server's 'ready' message. This avoid duplicated table
prepare/commit messages.

Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
Reviewed-by: Greg Farnum <greg@inktank.com>
 2013-04-01 09:16:59 -07:00
Yan, Zheng
a5dce808b5 mds: make sure table request id unique 
When a MDS becomes active, the table server re-sends 'agree' messages
for old prepared request. If the recoverd MDS starts a new table request
at the same time, The new request's ID can happen to be the same as old
prepared request's ID, because current table client code assigns request
ID from zero after MDS restarts.

This patch make table server send 'ready' messages when table clients
become active or itself becomes active. The 'ready' message updates
table client's last_reqid to avoid request ID collision. The message
also replaces the roles of finish_recovery() and handle_mds_recovery()
callbacks for table client.

Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
Reviewed-by: Greg Farnum <greg@inktank.com>
 2013-04-01 09:16:48 -07:00
Markus Elfring
f4b9d9d847 Bug #98: Unique names for include guards 
A couple of preprocessor symbols for include guards tampered with the reserved namespace.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Sage Weil <sage@newdream.net>
 2010-06-17 10:47:37 -07:00
Sage Weil
3768ef941e mds: do not bother tableserver until it is active 
We resend these requests when the TS does go active, and if we send dups
things get all screwed up (see partial log below).

Should we worry about dup queries?

10.06.02_22:32:08.112834 7f881dfdb910 -- 10.3.64.22:6802/7866 --> mds0 10.3.64.22:6803/13552 -- mds_table_request(anchortable prepare 69 148 bytes) v1 -- ?+0 0x7f88180e4580
10.06.02_22:32:08.116427 7f881dfdb910 mds1.tableserver(anchortable) handle_mds_recovery mds0
10.06.02_22:32:08.116449 7f881dfdb910 mds1.tableclient(anchortable) handle_mds_recovery mds0
10.06.02_22:32:08.116457 7f881dfdb910 mds1.tableclient(anchortable) resending 69
10.06.02_22:32:08.116470 7f881dfdb910 -- 10.3.64.22:6802/7866 --> mds0 10.3.64.22:6803/13552 -- mds_table_request(anchortable prepare 69 148 bytes) v1 -- ?+0 0x7f8818120cb0
10.06.02_22:32:08.116840 7f881dfdb910 -- 10.3.64.22:6802/7866 <== mds0 10.3.64.22:6803/13552 7 ==== mds_table_request(anchortable agree 69 tid 165) v1 ==== 16+0+0 (1328913316 0 0) 0x2362830
10.06.02_22:32:08.116861 7f881dfdb910 mds1.tableclient(anchortable) handle_request mds_table_request(anchortable agree 69 tid 165) v1
10.06.02_22:32:08.116872 7f881dfdb910 mds1.tableclient(anchortable) got agree on 69 atid 165
10.06.02_22:32:08.127662 7f881dfdb910 mds1.tableclient(anchortable) commit 165
10.06.02_22:32:08.127683 7f881dfdb910 -- 10.3.64.22:6802/7866 --> mds0 10.3.64.22:6803/13552 -- mds_table_request(anchortable commit tid 165) v1 -- ?+0 0x7f8818114860
10.06.02_22:32:08.128244 7f881dfdb910 mds1.tableclient(anchortable) _prepare 70
10.06.02_22:32:08.128261 7f881dfdb910 -- 10.3.64.22:6802/7866 --> mds0 10.3.64.22:6803/13552 -- mds_table_request(anchortable prepare 70 82 bytes) v1 -- ?+0 0x7f88180e4580
10.06.02_22:32:08.131873 7f881dfdb910 -- 10.3.64.22:6802/7866 <== mds0 10.3.64.22:6803/13552 8 ==== mds_table_request(anchortable agree 69 tid 165 148 bytes) v1 ==== 164+0+0 (4238497285 0 0) 0x2362310
10.06.02_22:32:08.131900 7f881dfdb910 mds1.tableclient(anchortable) handle_request mds_table_request(anchortable agree 69 tid 165 148 bytes) v1
10.06.02_22:32:08.131911 7f881dfdb910 mds1.tableclient(anchortable) stray agree on 69 tid 165, already committing, resending COMMIT
10.06.02_22:32:08.131923 7f881dfdb910 -- 10.3.64.22:6802/7866 --> mds0 10.3.64.22:6803/13552 -- mds_table_request(anchortable commit tid 165) v1 -- ?+0 0x7f8818120cb0
10.06.02_22:32:08.144147 7f881dfdb910 -- 10.3.64.22:6802/7866 <== mds0 10.3.64.22:6803/13552 10 ==== mds_table_request(anchortable ack tid 165) v1 ==== 16+0+0 (584840829 0 0) 0x246dd20
10.06.02_22:32:08.144179 7f881dfdb910 mds1.tableclient(anchortable) handle_request mds_table_request(anchortable ack tid 165) v1
10.06.02_22:32:08.144195 7f881dfdb910 mds1.tableclient(anchortable) got ack on tid 165, logging
10.06.02_22:32:08.144217 7f881dfdb910 mds1.log submit_entry 5515297~17 : ETableClient anchortable ack tid 165
10.06.02_22:32:08.152419 7f881dfdb910 -- 10.3.64.22:6802/7866 <== mds0 10.3.64.22:6803/13552 11 ==== mds_table_request(anchortable agree 69 tid 166 148 bytes) v1 ==== 164+0+0 (4238497285 0 0) 0x2362830
10.06.02_22:32:08.152448 7f881dfdb910 mds1.tableclient(anchortable) handle_request mds_table_request(anchortable agree 69 tid 166 148 bytes) v1
10.06.02_22:32:08.152460 7f881dfdb910 mds1.tableclient(anchortable) stray agree on 69 tid 166, sending ROLLBACK
10.06.02_22:32:08.152470 7f881dfdb910 -- 10.3.64.22:6802/7866 --> mds0 10.3.64.22:6803/13552 -- mds_table_request(anchortable rollback tid 166) v1 -- ?+0 0x7f8818120cb0
10.06.02_22:32:08.172729 7f881dfdb910 -- 10.3.64.22:6802/7866 <== mds0 10.3.64.22:6803/13552 13 ==== mds_table_request(anchortable ack tid 165) v1 ==== 16+0+0 (584840829 0 0) 0x2362310
10.06.02_22:32:08.172770 7f881dfdb910 mds1.tableclient(anchortable) handle_request mds_table_request(anchortable ack tid 165) v1
10.06.02_22:32:08.172786 7f881dfdb910 mds1.tableclient(anchortable) got ack on tid 165, logging
10.06.02_22:32:08.172806 7f881dfdb910 mds1.log submit_entry 5515318~17 : ETableClient anchortable ack tid 165
10.06.02_22:32:08.174091 7f881dfdb910 -- 10.3.64.22:6802/7866 <== mds0 10.3.64.22:6803/13552 14 ==== mds_table_request(anchortable agree 70 tid 168 82 bytes) v1 ==== 98+0+0 (1154743153 0 0) 0x246dd20
10.06.02_22:32:08.174119 7f881dfdb910 mds1.tableclient(anchortable) handle_request mds_table_request(anchortable agree 70 tid 168 82 bytes) v1
10.06.02_22:32:08.174131 7f881dfdb910 mds1.tableclient(anchortable) got agree on 70 atid 168
10.06.02_22:32:08.202508 7f881dfdb910 mds1.tableclient(anchortable) _logged_ack 165
10.06.02_22:32:08.202530 7f881dfdb910 mds1.tableclient(anchortable) _logged_ack 165
<crash>
 2010-06-02 23:07:42 -07:00
Sage Weil
edc92490b5 types: standardize on uint64_t 
The problem is that on some platforms __u64 == uint64_t (x86_64), and on
others it's doesn't (ppc64).  Which means we don't know whether to define
different versions of overloaded functions for both types or just one.

So, standardize on uint64_t.  This plays nicer with STL, which defines
hash<uint64_t> on 64 bit arches but not 32 bit.  Which means we can't
standarzie on __u64 or else hash<__u64> won't work.  Bah!
 2010-05-07 14:50:20 -07:00
Sage Weil
f7954f3782 mds: cut back on hash_map usage 
These use lots of memory, and aren't necessary for smallish maps.
 2009-06-11 10:32:15 -07:00
Sage Weil
37cd4a2b11 mds: update log segment tid list on journaled tableclient ack 2008-10-20 13:39:53 -07:00
Sage Weil
326b17f540 mds: allocate consecutive snapids 2008-08-07 14:38:15 -07:00
Sage Weil
2b8f15a29d mds: missing constructor 2008-07-23 09:45:43 -07:00
Sage Weil
77a92f2270 mds: snaptable -> snapserver+snapclient 2008-07-16 15:41:11 -07:00
Sage Weil
586236c536 mds: refactor Anchor{Table,Client} into MDSTable{Server,Client} 2008-07-16 13:46:09 -07:00