Skip to content
This repository has been archived by the owner on May 3, 2024. It is now read-only.

CORTX-31907- panic at m0_balloc_load_extents() #2064

Merged
merged 5 commits into from
Aug 9, 2022

Conversation

mukundkanekar
Copy link
Contributor

@mukundkanekar mukundkanekar commented Aug 9, 2022

Problem Statement

  • Intermediate return in alloc/free_db_update() functions can cause Balloc Extent btree and Balloc Group Desc btree to go out of sync since cleanup is not done correctly. During reload of the group inconsistencies in these 2 balloc btree's leads to panic at m0_balloc_load_extents(). Once data is persistent any future reload of same group will leads to recurring panic even after restart.

Design

  • Added assert when there is an intermediate return in alloc/free_db_update() due to error. This will avoid inconstancies in 2 balloc btree's to become persistent and will avoid multiple subsequent panic at m0_balloc_load_extents().

Coding

Checklist for Author

  • [x ] Coding conventions are followed and code is consistent

Testing

Checklist for Author

  • Unit and System Tests are added
  • Test Cases cover Happy Path, Non-Happy Path and Scalability
  • Testing was performed with RPM
  • balloc-ut is successful.
  • Deployment of custom build 7496 (Base main build 890) succeeded on HW

Impact Analysis

Checklist for Author/Reviewer/GateKeeper

  • Interface change (if any) are documented
  • Side effects on other features (deployment/upgrade)
  • Dependencies on other component(s)

Review Checklist

Checklist for Author

  • JIRA number/GitHub Issue added to PR
  • PR is self reviewed
  • Jira and state/status is updated and JIRA is updated with PR link
  • Check if the description is clear and explained

Documentation

Checklist for Author

  • Changes done to WIKI / Confluence page / Quick Start Guide

1. Added assert in balloc code in case any btree operation fails.
2. Added debug print in btree code to print error messages specific balloc
btrees.

Signed-off-by: Mukund Kanekar <mukund.kanekar@seagate.com>
in sync with new btree code.

Signed-off-by: Mukund Kanekar <mukund.kanekar@seagate.com>
alloc/free db update returns error.

Signed-off-by: Mukund Kanekar <mukund.kanekar@seagate.com>
@mukundkanekar
Copy link
Contributor Author

@hessio hessio added the Status: Waiting to be merged PR is waiting for a gatekeeper to merge it label Aug 9, 2022
@rkothiya
Copy link
Contributor

rkothiya commented Aug 9, 2022

Jenkins CI Result : Motr#1575

Motr Test Summary

Test ResultCountInfo
❌Failed2
📁

04motr-single-node/49motr-rpc-cancel
01motr-single-node/00userspace-tests

🏁Skipped32
📁

01motr-single-node/28sys-kvs
01motr-single-node/35m0singlenode
01motr-single-node/04initscripts
01motr-single-node/37protocol
02motr-single-node/51kem
02motr-single-node/20rpc-session-cancel
02motr-single-node/10pver-assign
02motr-single-node/21fsync-single-node
02motr-single-node/13dgmode-io
02motr-single-node/14poolmach
02motr-single-node/11m0t1fs
02motr-single-node/26motr-user-kernel-tests
02motr-single-node/08spiel
03motr-single-node/06conf
03motr-single-node/36spare-reservation
04motr-single-node/34sns-repair-1n-1f
04motr-single-node/08spiel-sns-repair-quiesce
04motr-single-node/28sys-kvs-kernel
04motr-single-node/11m0t1fs-rconfc-fail
04motr-single-node/08spiel-sns-repair
04motr-single-node/19sns-repair-abort
04motr-single-node/22sns-repair-ios-fail
05motr-single-node/18sns-repair-quiesce
05motr-single-node/12fwait
05motr-single-node/16sns-repair-multi
05motr-single-node/07mount-fail
05motr-single-node/15sns-repair-single
05motr-single-node/23sns-abort-quiesce
05motr-single-node/17sns-repair-concurrent-io
05motr-single-node/07mount
05motr-single-node/07mount-multiple
05motr-single-node/12fsync

✔️Passed41
📁

01motr-single-node/43m0crate
01motr-single-node/05confgen
01motr-single-node/06hagen
01motr-single-node/52motr-singlenode-sanity
01motr-single-node/01net
01motr-single-node/01kernel-tests
01motr-single-node/03console
01motr-single-node/02rpcping
02motr-single-node/07m0d-fatal
02motr-single-node/67fdmi-plugin-multi-filters
02motr-single-node/53clusterusage-alert
02motr-single-node/41motr-conf-update
03motr-single-node/61sns-repair-motr-1n-1f
03motr-single-node/72spiel-sns-motr-repair-quiesce
03motr-single-node/08spiel-multi-confd
03motr-single-node/69sns-repair-motr-quiesce
03motr-single-node/62sns-repair-motr-mf
03motr-single-node/70sns-failure-after-repair-quiesce
03motr-single-node/63sns-repair-motr-1k-1f
03motr-single-node/60sns-repair-motr-1f
03motr-single-node/66sns-repair-motr-abort-quiesce
03motr-single-node/24motr-dix-repair-lookup-insert-spiel
03motr-single-node/68sns-repair-motr-shutdown
03motr-single-node/64sns-repair-motr-ios-fail
03motr-single-node/71spiel-sns-motr-repair
03motr-single-node/24motr-dix-repair-lookup-insert-m0repair
03motr-single-node/04sss
03motr-single-node/65sns-repair-motr-abort
04motr-single-node/48motr-raid0-io
04motr-single-node/25m0kv
04motr-single-node/44motr-rm-lock-cc-io
04motr-single-node/45motr-rmw
05motr-single-node/23dix-repair-m0repair
05motr-single-node/43motr-sync-replication
05motr-single-node/42motr-utils
05motr-single-node/45motr-sns-repair-N-1
05motr-single-node/40motr-dgmode
05motr-single-node/23dix-repair-quiesce-m0repair
05motr-single-node/23spiel-dix-repair-quiesce
05motr-single-node/44motr-sns-repair
05motr-single-node/23spiel-dix-repair

Total75🔗

CppCheck Summary

   Cppcheck: No new warnings found 👍

@rkothiya rkothiya merged commit 705e891 into Seagate:main Aug 9, 2022
@huanghua78
Copy link

huanghua78 commented Aug 9, 2022

  • Added assert when there is an intermediate return in alloc/free_db_update() due to error. This will avoid inconstancies in 2 balloc btree's to become persistent and will avoid multiple subsequent panic at m0_balloc_load_extents().

I am not sure here.

  1. an intermediate return in alloc/free_db_update() due to error. If this happens, we should do cleanup properly. Also, the transaction should be aborted due to error, so the previous update will not be flushed to persistent storage.
  2. If we assert() and panic() due to error, this will cause interrupt of service. And are we sure, when the failed m0d service is restarted, the error will not happen again and cause repeated panic?

@mukundkanekar
Copy link
Contributor Author

  • Added assert when there is an intermediate return in alloc/free_db_update() due to error. This will avoid inconstancies in 2 balloc btree's to become persistent and will avoid multiple subsequent panic at m0_balloc_load_extents().

I am not sure here.

  1. an intermediate return in alloc/free_db_update() due to error. If this happens, we should do cleanup properly. Also, the transaction should be aborted due to error, so the previous update will not be flushed to persistent storage.
  2. If we assert() and panic() due to error, this will cause interrupt of service. And are we sure, when the failed m0d service is restarted, the error will not happen again and cause repeated panic?
  1. an intermediate return in alloc/free_db_update() due to error. If this happens, we should do cleanup properly. Also, the transaction should be aborted due to error, so the previous update will not be flushed to persistent storage.

We have observed that return from alloc/free_db_update with error doesn't skip the transaction update.
We used below patch to return temporary error from balloc.

# git diff
diff --git a/balloc/balloc.c b/balloc/balloc.c
index 7ecaa431..1e9d03e2 100644
--- a/balloc/balloc.c
+++ b/balloc/balloc.c
@@ -1678,7 +1678,7 @@ static int balloc_alloc_db_update(struct m0_balloc *motr, struct m0_be_tx *tx,
        int                          rc = 0;
        m0_bcount_t                  maxchunk;

-       M0_ENTRY();
+       M0_ENTRY("tx=%p", tx);
        M0_PRE(m0_mutex_is_locked(bgi_mutex(grp)));
        M0_PRE(!is_any(alloc_type));
        M0_PRE(M0_IN(alloc_type, (M0_BALLOC_SPARE_ZONE,
@@ -1785,6 +1785,7 @@ static int balloc_alloc_db_update(struct m0_balloc *motr, struct m0_be_tx *tx,

        rc = balloc_gi_sync(motr, tx, grp);

+       rc = -ENOMEM;
        return M0_RC(rc);
 }

@@ -1805,7 +1806,7 @@ static int balloc_free_db_update(struct m0_balloc *motr,
        int                          rc = 0;
        int                          found = 0;

-       M0_ENTRY();
+       M0_ENTRY("tx=%p", tx);
        M0_PRE(m0_mutex_is_locked(bgi_mutex(grp)));

        balloc_debug_dump_extent("target=", tgt);
@@ -2018,6 +2019,7 @@ static int balloc_free_db_update(struct m0_balloc *motr,

        rc = balloc_gi_sync(motr, tx, grp);

+       rc = -ENOMEM;
        return M0_RC(rc);
 }

Then used below command to extract snippet from trace

# ./utils/trace/m0trace -i /var/motr/m0d-0x7200000000000001\:0x2/m0trace.53259.2022-08-12-01\:30\:58 | egrep 'balloc_alloc_db_update|ext_punch|m0_be_group_format_seg_place|m0_be_tx_close|tx_group_fom_tick|0x7f0f78022bb0|0x2135040'

Still see that tx=0x7f0f78022bb0 group=0x2135040 gets logged, below is snippet from trace file,

120537  27141584.675.300004  7f1006ff4c80  CALL    be/tx_group_fom.c:158:tx_group_fom_tick             > tx_group_fom=0x2139a58 group=0x2137c00 phase=TGS_OPEN
121167  27141584.708.468584  7f0f9e7fb8c0  DEBUG   be/engine.c:646:m0_be_engine__tx_state_set          tx 0x7f0f78022bb0: => prepare
121168  27141584.708.469088  7f0f9e7fb8c0  DEBUG   be/engine.c:657:m0_be_engine__tx_state_set          tx=0x7f0f78022bb0 t_id=12
121169  27141584.708.470464  7f0f9e7fb8d0  CALL    be/tx.c:389:m0_be_tx_get                            > tx=0x7f0f78022bb0 t_ref=0 state=prepare
121190  27141584.708.978384  7f0f9e7fb940  CALL    be/tx.c:275:m0_be_tx_payload_prep                   > tx=0x7f0f78022bb0 size=262144
121191  27141584.708.986818  7f0f9e7fb910  CALL    be/tx.c:265:m0_be_tx_prep                           > tx=0x7f0f78022bb0 credit=(37215,7816309)
121192  27141584.708.987724  7f0f9e7fb910  CALL    be/tx.c:286:m0_be_tx_open                           > tx=0x7f0f78022bb0 t_prepared=(37215,7816309) t_payload_prepared=262144
121193  27141584.708.988876  7f0f9e7fb820  CALL    be/tx.c:523:be_tx_state_move                        > tx=0x7f0f78022bb0 rc=0 prepare -> opening
121194  27141584.708.997140  7f0f9e7fb7d0  DEBUG   be/engine.c:646:m0_be_engine__tx_state_set          tx 0x7f0f78022bb0: => opening
121197  27141584.709.033744  7f0f9e7fb720  DEBUG   be/tx.c:586:m0_be_tx__state_post                    tx=0x7f0f78022bb0 state=grouping
121212  27141584.709.070186  7f0f9e7fbc00  CALL    be/tx.c:440:be_tx_state_move_ast                    > tx=0x7f0f78022bb0 opening -> grouping
121213  27141584.709.070672  7f0f9e7fbb10  CALL    be/tx.c:523:be_tx_state_move                        > tx=0x7f0f78022bb0 rc=0 opening -> grouping
121214  27141584.709.077056  7f0f9e7fbac0  DEBUG   be/engine.c:646:m0_be_engine__tx_state_set          tx 0x7f0f78022bb0: => grouping
121215  27141584.709.082028  7f0f9e7fb950  CALL    be/tx_group.c:297:m0_be_tx_group_tx_add             > gr=0x2135040 tx=0x7f0f78022bb0 t_prepared=(37215,7816309) t_payload_prepared=262144 tg_used=(0,0) tg_payload_prepared=0 group_tx_nr=0
121216  27141584.709.083082  7f0f9e7fb920  DEBUG   be/tx_group.c:279:be_tx_group_tx_add                tx=0x7f0f78022bb0 group=0x2135040
121218  27141584.709.089772  7f0f9e7fba10  CALL    be/engine.c:430:be_engine_group_timeout_arm         > en=0x7ffd24277e98 gr=0x2135040 sm_grp=0x18fc120
121220  27141584.709.114010  7f0f9e7fb9e0  DEBUG   be/tx.c:586:m0_be_tx__state_post                    tx=0x7f0f78022bb0 state=active
121223  27141584.709.120288  7f0f9e7fbc00  CALL    be/tx.c:440:be_tx_state_move_ast                    > tx=0x7f0f78022bb0 grouping -> active
121224  27141584.709.120666  7f0f9e7fbb10  CALL    be/tx.c:523:be_tx_state_move                        > tx=0x7f0f78022bb0 rc=0 grouping -> active
121234  27141584.709.203562  7f0f9e7fbac0  DEBUG   be/engine.c:646:m0_be_engine__tx_state_set          tx 0x7f0f78022bb0: => active
121236  27141584.709.231434  7f1006ff4c00  CALL    be/engine.c:360:be_engine_group_timer_arm           > en=0x7ffd24277e98 gr=0x2135040 sm_grp=0x18fc120
121317  27141584.709.780912  7f0f9e7fa0a0  CALL    balloc/balloc.c:1681:balloc_alloc_db_update         > tx=0x7f0f78022bb0
121320  27141584.709.795236  7f0f9e7fa0a0  DEBUG   balloc/balloc.c:1708:balloc_alloc_db_update         bzp_maxchunk=0x8000 next_maxchunk=0x0
121325  27141584.710.032306  7f0f9e7fa0a0  CALL    balloc/balloc.c:1789:balloc_alloc_db_update         < rc=-12
121364  27141584.710.484734  7f0f9e7fb960  CALL    be/tx.c:389:m0_be_tx_get                            > tx=0x7f0f78022bb0 t_ref=1 state=active
121372  27141584.710.494304  7f0f9e7fb860  CALL    be/tx.c:377:m0_be_tx_close                          > tx=0x7f0f78022bb0
121373  27141584.710.519894  7f0f9e7fb770  CALL    be/tx.c:523:be_tx_state_move                        > tx=0x7f0f78022bb0 rc=0 active -> closed
121374  27141584.710.530972  7f0f9e7fb720  DEBUG   be/engine.c:646:m0_be_engine__tx_state_set          tx 0x7f0f78022bb0: => closed
121375  27141584.710.535498  7f0f9e7fb5c0  DEBUG   be/tx_group.c:347:m0_be_tx_group_tx_closed          gr=0x2135040 tx=0x7f0f78022bb0 tx_prepared=(37215,7816309) t_payload_prepared=262144 tg_used=(37215,7816309) tg_payload_prepared=262144
121376  27141584.710.536252  7f0f9e7fb5c0  DEBUG   be/tx_group.c:357:m0_be_tx_group_tx_closed          gr=0x2135040 tx=0x7f0f78022bb0 tx_captured=(17,5070) t_payload.b_nob=6432 tg_used=(17,5070) tg_payload_prepared=6432
121381  27141584.710.564930  7f0f9e7fb860  CALL    be/tx.c:383:m0_be_tx_close                          <
121391  27141584.712.260844  7f1006ff4c00  CALL    be/engine.c:342:be_engine_group_timer_cb            > en=0x7ffd24277e98 gr=0x2135040 sm_grp=0x18fc120
121392  27141584.712.263278  7f1006ff4b90  CALL    be/engine.c:74:be_engine_tx_group_state_move        > en=0x7ffd24277e98 gr=0x2135040 state=2 gr->tg_state=1
121393  27141584.712.266856  7f1006ff4b70  CALL    be/engine.c:74:be_engine_tx_group_state_move        > en=0x7ffd24277e98 gr=0x2135040 state=3 gr->tg_state=2
121394  27141584.712.268704  7f1006ff4a70  CALL    be/tx_group.c:154:m0_be_tx_group_close              > gr=0x2135040 recovering=0
121395  27141584.712.270476  7f1006ff4a70  DEBUG   be/tx_group.c:91:be_tx_group_reg_area_gather        gr=0x2135040 tx_nr=1
121396  27141584.712.317538  7f1006ff4a70  DEBUG   be/tx_group.c:107:be_tx_group_reg_area_gather       tx=0x7f0f78022bb0 t_prepared=(37215,7816309) t_payload_prepared=262144 captured=(17,5070) used=(17,5070) t_payload.b_nob=6432
121400  27141584.712.754126  7f1006ff4a20  CALL    be/tx.c:794:m0_be_tx_lsn_set                        < tx=0x7f0f78022bb0 t_lsn=2158592 t_lsn_discarded=2007040
121406  27141584.712.782954  7f1006ff4c00  CALL    be/engine.c:376:be_engine_group_timer_disarm        > en=0x7ffd24277e98 gr=0x2135040 sm_grp=0x18fc120
121410  27141584.712.851918  7f1006ff4c80  CALL    be/tx_group_fom.c:158:tx_group_fom_tick             > tx_group_fom=0x2136e98 group=0x2135040 phase=TGS_PREPARE
121412  27141584.712.915636  7f1006ff4c80  CALL    be/tx_group_fom.c:158:tx_group_fom_tick             > tx_group_fom=0x2136e98 group=0x2135040 phase=TGS_LOGGING
121444  27141584.715.296892  7f1006ff4c80  CALL    be/tx_group_fom.c:158:tx_group_fom_tick             > tx_group_fom=0x2136e98 group=0x2135040 phase=TGS_PLACING
121445  27141584.715.299464  7f1006ff4c00  CALL    be/tx_group.c:449:m0_be_tx_group__tx_state_post     > gr=0x2135040 state=logged group_tx_nr=1
121446  27141584.715.300880  7f1006ff4bd0  DEBUG   be/tx.c:586:m0_be_tx__state_post                    tx=0x7f0f78022bb0 state=logged
121448  27141584.715.368838  7f1006ff4c40  DEBUG   be/tx_group_format.c:578:m0_be_group_format_seg_place   seg_place ldi=0x21349f0
121456  27141584.715.388892  7f0f9e7fbc00  CALL    be/tx.c:440:be_tx_state_move_ast                    > tx=0x7f0f78022bb0 closed -> logged
121457  27141584.715.390072  7f0f9e7fbb10  CALL    be/tx.c:523:be_tx_state_move                        > tx=0x7f0f78022bb0 rc=0 closed -> logged
121460  27141584.715.416314  7f0f9e7fbac0  DEBUG   be/engine.c:646:m0_be_engine__tx_state_set          tx 0x7f0f78022bb0: => logged
121624  27141584.715.907064  7f0f9e7fb950  CALL    be/tx.c:399:m0_be_tx_put                            > tx=0x7f0f78022bb0 t_ref=2 state=logged
121650  27141584.716.030106  7f1006ff4c80  CALL    be/tx_group_fom.c:158:tx_group_fom_tick             > tx_group_fom=0x2136e98 group=0x2135040 phase=TGS_PLACED
121652  27141584.716.031638  7f1006ff4c00  CALL    be/tx_group.c:449:m0_be_tx_group__tx_state_post     > gr=0x2135040 state=placed group_tx_nr=1
121653  27141584.716.032328  7f1006ff4bd0  DEBUG   be/tx_group.c:378:m0_be_tx_group_tx_del             tx=0x7f0f78022bb0 gr=0x2135040
121658  27141584.716.042868  7f1006ff4bd0  DEBUG   be/tx.c:586:m0_be_tx__state_post                    tx=0x7f0f78022bb0 state=placed
121667  27141584.716.074414  7f1006ff4c80  CALL    be/tx_group_fom.c:158:tx_group_fom_tick             > tx_group_fom=0x2136e98 group=0x2135040 phase=TGS_STABILIZING
121679  27141584.716.091046  7f0f9e7fbc00  CALL    be/tx.c:440:be_tx_state_move_ast                    > tx=0x7f0f78022bb0 logged -> placed
121681  27141584.716.091712  7f0f9e7fbb10  CALL    be/tx.c:523:be_tx_state_move                        > tx=0x7f0f78022bb0 rc=0 logged -> placed
121691  27141584.716.110228  7f0f9e7fbac0  DEBUG   be/engine.c:646:m0_be_engine__tx_state_set          tx 0x7f0f78022bb0: => placed
121692  27141584.716.111260  7f0f9e7fbad0  CALL    be/tx.c:399:m0_be_tx_put                            > tx=0x7f0f78022bb0 t_ref=1 state=placed
121693  27141584.716.112740  7f0f9e7fbaa0  DEBUG   be/tx.c:586:m0_be_tx__state_post                    tx=0x7f0f78022bb0 state=done
121696  27141584.716.120634  7f0f9e7fbc00  CALL    be/tx.c:440:be_tx_state_move_ast                    > tx=0x7f0f78022bb0 placed -> done
121697  27141584.716.121056  7f0f9e7fbb10  CALL    be/tx.c:523:be_tx_state_move                        > tx=0x7f0f78022bb0 rc=0 placed -> done
121699  27141584.716.139160  7f0f9e7fbac0  DEBUG   be/engine.c:646:m0_be_engine__tx_state_set          tx 0x7f0f78022bb0: => done
121711  27141584.716.195794  7f0f9e7fb940  CALL    be/tx.c:241:m0_be_tx_fini                           > tx=0x7f0f78022bb0
121712  27141584.716.226086  7f1006ff4c80  CALL    be/tx_group_fom.c:158:tx_group_fom_tick             > tx_group_fom=0x2136e98 group=0x2135040 phase=TGS_STABILIZING
121714  27141584.716.234914  7f1006ff4c80  CALL    be/tx_group_fom.c:158:tx_group_fom_tick             > tx_group_fom=0x2136e98 group=0x2135040 phase=TGS_STABLE
121716  27141584.716.243354  7f1006ff4c80  CALL    be/tx_group_fom.c:158:tx_group_fom_tick             > tx_group_fom=0x2136e98 group=0x2135040 phase=TGS_RESET
121717  27141584.716.263740  7f1006ff4c40  CALL    be/engine.c:741:m0_be_engine__tx_group_ready        > en=0x7ffd24277e98 gr=0x2135040
  1. If we assert() and panic() due to error, this will cause interrupt of service. And are we sure, when the failed m0d service is restarted, the error will not happen again and cause repeated panic?

Panic on error will avoid the failed transaction getting logged, so mismatch in balloc btree's will not become persistent, Custom build #7496 in under test from last 3 days to confirm this.

kiwionly2 pushed a commit to kiwionly2/cortx-motr that referenced this pull request Aug 30, 2022
Custom build to debug balloc assert due to corrupt btree.

1. Added assert in balloc code in case any btree operation fails.
2. Added debug print in btree code to print error messages specific balloc btrees.
3. Updated assert added in balloc code in when btree operation fails in sync with new btree code.
4. Added assert in case ext creation fails due low memory also if alloc/free db update returns error.

Signed-off-by: Mukund Kanekar <mukund.kanekar@seagate.com>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
cla-signed Status: Waiting to be merged PR is waiting for a gatekeeper to merge it
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants