diff options
author | Avra Sengupta <asengupt@redhat.com> | 2014-03-06 08:23:01 +0000 |
---|---|---|
committer | Rajesh Joseph <rjoseph@redhat.com> | 2014-04-02 06:03:50 -0700 |
commit | bff28bca0e79d67ecdec0ff7a240570b56fdcd7c (patch) | |
tree | b5f63c1e39e34933cb5c775375f9e3c018e13163 /xlators/bindings/python | |
parent | 0ce369a0aa511e98fd71c0337181a5577b2d8a1f (diff) |
glusterd/snapshot: Recording the snapshots missed in each brick.
Persisting missing snapshot info on disk as well as in memory in
the following format:
-------------NODE-UUID--------------:---------SNAP-UUID--------------=BRICKNUM:-------BRICKPATH--------:OPERATION:STATUS
927cb5fe-63da-48f5-82f6-e6a09ddc81c4:a17b4fe42c5a45f7a916438643edaa13= 3 :/brick/brick-dirs/brick3: 1 : 1
927cb5fe-63da-48f5-82f6-e6a09ddc81c4:a17b4fe42c5a45f7a916438643edaa13= 3 :/brick/brick-dirs/brick3: 3 : 1
927cb5fe-63da-48f5-82f6-e6a09ddc81c4:83a3cc05453b46b2a7eda4c9a9208638= 3 :/brick/brick-dirs/brick3: 1 : 1
This data will be stored on disk at /var/lib/glusterd/snaps/missed_snaps_list
In memory we maintain the data as a list of glusterd_missed_snap_info
in conf, the key for this list are the first two fields,
i.e NODE-UUID:SNAP-UUID.
For every NODE-UUID:SNAP-UUID, there can be multiple operations missed
on multiple bricks. So we maintain a list of glusterd_snap_op_t
for evert node of glusterd_missed_snap_info
This list is maintained or updated during snapshot create, delete, and restore
operations which are the only operations that if missed, are recorded in this
list.
During snapshot create, if a node is down, or a brick is down, we don't
receive their mount point infos. snap_status of such bricks is marked as
-1, and their brick details are added to this list.
During snapshot delete, we check from originator node, if any other
nodes, holding bricks of the said snap are down. Those are also added to the list.
Also if the node is up, but the snapshot was pending for a snap
brick, and its snap_status is -1, we add that to the list too.
When a subsequent delete entry is processed for an already existing
create entry, we just mark the create entries status as done (2), and don't
add the delete entry to the list.
During snapshot restore, we check from originator node, if any other
nodes, holding bricks of the said snap are down. Those are also added to the list.
Also if the node is up, but the snapshot was pending for a snap
brick, and its snap_status is -1, we add that to the list too.
Change-Id: I22578d14f81a54e13f6832966b70cd4cfdfd5b44
Signed-off-by: Avra Sengupta <asengupt@redhat.com>
Reviewed-on: http://review.gluster.org/7208
Reviewed-by: Vijaikumar Mallikarjuna <vmallika@redhat.com>
Reviewed-by: Rajesh Joseph <rjoseph@redhat.com>
Tested-by: Rajesh Joseph <rjoseph@redhat.com>
Diffstat (limited to 'xlators/bindings/python')
0 files changed, 0 insertions, 0 deletions