Motr
M0
|
#include "motr/addb.h"
#include "motr/client.h"
#include "motr/client_internal.h"
#include "motr/sync.h"
#include "lib/trace.h"
#include "lib/finject.h"
#include "mdservice/fsync_fops.h"
#include "fop/fom_generic.h"
#include "lib/memory.h"
#include "lib/tlist.h"
#include "lib/hash.h"
#include "file/file.h"
#include "motr/magic.h"
#include "pool/pool.h"
Go to the source code of this file.
Macros | |
#define | M0_TRACE_SUBSYSTEM M0_TRACE_SUBSYS_CLIENT |
Variables | |
static const struct m0_bob_type | os_bobtype |
static struct sync_interactions | si |
static const struct m0_rpc_item_ops | sync_ri_ops |
M0_BOB_DEFINE | ( | static | , |
& | os_bobtype, | ||
m0_op_sync | |||
) |
M0_TL_DEFINE | ( | sync_target | , |
static | , | ||
struct sync_target | |||
) |
M0_TL_DEFINE | ( | spf | , |
static | , | ||
struct sync_fop_wrapper | |||
) |
M0_TL_DEFINE | ( | spti | , |
M0_INTERNAL | , | ||
struct m0_reqh_service_txid | |||
) |
M0_TL_DESCR_DEFINE | ( | sync_target | , |
"Targets to synced for a client SYNC request" | , | ||
static | , | ||
struct sync_target | , | ||
srt_tlink | , | ||
srt_tlink_magic | , | ||
M0_SYNC_TGT_TL_MAGIC | , | ||
M0_SYNC_TGT_TL_MAGIC | |||
) |
M0_TL_DESCR_DEFINE | ( | spf | , |
"sync_fop_wrappers pending fsync-fops" | , | ||
static | , | ||
struct sync_fop_wrapper | , | ||
sfw_tlink | , | ||
sfw_tlink_magic | , | ||
M0_T1FS_FFW_TLIST_MAGIC1 | , | ||
M0_T1FS_FFW_TLIST_MAGIC2 | |||
) |
M0_TL_DESCR_DEFINE | ( | spti | , |
"m0_reqh_service_txid pending list" | , | ||
M0_INTERNAL | , | ||
struct m0_reqh_service_txid | , | ||
stx_tlink | , | ||
stx_link_magic | , | ||
M0_INSTANCE_PTI_MAGIC | , | ||
M0_INSTANCE_PTI_MAGIC | |||
) |
|
static |
|
static |
|
static |
|
static |
Update stx (m0_reqh_service_txid) of an entity or op after receiving FSYNC FOP reply from service.
Definition at line 244 of file sync.c.
|
static |
|
static |
|
static |
|
static |
|
static |
|
static |
void sync_record_update | ( | struct m0_reqh_service_ctx * | service, |
struct m0_entity * | ent, | ||
struct m0_op * | op, | ||
struct m0_be_tx_remid * | btr | ||
) |
Updates a m0_reqh_service_txid with the specified be_tx_remid if the struct m0_be_tx_remid::tri_txid > the stored value obj may be NULL if the update has no associated inode.
Definition at line 788 of file sync.c.
|
static |
|
static |
|
static |
|
static |
|
static |
|
static |
Creates and sends an fsync fop from the provided m0_reqh_service_txid. Allocates and returns the fop wrapper at on success, which is freed on the last m0_fop_put().
Definition at line 411 of file sync.c.
|
static |
|
static |
|
static |
Client sends an fsync-fop to a list of services, then blocks, waiting for replies. This is implemented as two loops. The 'fop sending loop', generates and posts fops, adding them to a list of pending fops. This is all done while holding the m0__entity::en_pending_tx_lock. The 'reply receiving loop' works over the list of pending fops, waiting for a reply for each one. It acquires the m0_obj::ob_pending_tx_map_lock only when necessary.
Definition at line 600 of file sync.c.
|
static |
|
static |
|
static |
|
static |
Client SYNC APIs follow the design described in m0t1fs/linux_kernel/fsync.h and are implemented with the following modifications/extensions.
(1) 3 APIs are added to create/initialise SYNC op and to add entities and operations to sync: m0_sync_op_init(): create a new SYNC op. m0_sync_entity_add(): Add an entity to SYNC op. m0_sync_op_add(): Add an op to SYNC op. The op can only added if its state is M0_OS_STABLE or M0_OS_EXECUTED.
m0t1fs_fsync() and m0t1fs_sync_fs() are changed to m0__entity_fsync() and m0_sync() respectively.
(2) Add support to sync index. A new fop type m0_fop_fsync_cas_fopt is added. See its definition in cas/cas.c. CAS handles FSYNC fops as IOS and MDS do by setting fom_ops to &m0_fsync_fom_ops and sm to &m0_fsync_fom_conf.
(3) For index UPDATE queries such as PUT and DEL, CAS piggy-backs the latest txid of an CAS servie in reply fop (via m0_cas_rep::cgr_mod_rep).
(4) Client maintains a list of {service, txid} pairs for each SYNC op. This list is constructed/updated when new elements are added to SYNC op. For a newly added pair {svc, t2}, if there exists a pair {svc, t1} in the list, these 2 pairs are merged into one {svc, max(t1, t2)}.
(5) An SYNC op (and request) may send multiple FSYNC fops to services. The process of reply fops is: (a) The rpc item callback, sync_ri_callback() is called to invoke the fop AST, sync_fop_ast, to process the reply fop. (b) Posts SYNC request's AST, sync_request_ast, if it is the last reply fop for the SYNC request. (c) SYNC op's state is moved to STABLE only if every FSYNC fop is executed successfully.
(6) Each entity and op has a list of pending service txid. The pending txid is updated when any UPDATE fop on entity is replied with latest txid of a service. The update process is added for dix/cas. Updating txid for cas is straightforward. For dix, an function pointer m0_dix_cli::dx_sync_rec_update is added and client related information (entity and op) is passed to dix via m0_dix_req::dr_sync_datum.
|
static |
Ugly abstraction of sync interactions with wider motr code
|
static |
RPC callbacks for the posting of FSYNC fops to services.