Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Added info about the daemon's config interval consumption redesign #1703

Merged
merged 2 commits into from
May 23, 2024
Merged

Added info about the daemon's config interval consumption redesign #1703

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
2551687
Added info about the daemon's config interval consumption redesign
assrinivasan May 23, 2024
9537c6b
or --> and
assrinivasan May 23, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions doc/storagemond/storagemond-hld.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -61,15 +61,17 @@ These fields are self-explanatory.

1. The "storagemond" process will be initiated by the "pmon" Docker container.

2. As part of initialization process, the daemon will query the Config DB for fields called `daemon_polling_interval` and `fsstats_sync_interval` within a newly proposed table `STORMOND_CONFIG|INTERVALS` and use the value to set the looping frequency for getting dynamic informaton and syncing this information to disk, respectively. In the absense of this table/field, we would default to 3600 seconds for the polling interval and 86400 seconds for sync interval.
2. Shortly succeeding the initialization process, the daemon will query the Config DB for fields called `daemon_polling_interval` and `fsstats_sync_interval` within a newly proposed table `STORMOND_CONFIG|INTERVALS` and use the value to set the looping frequency for getting dynamic informaton and syncing this information to disk, respectively<sup>NOTE</sup>. In the absense of this table/field, we would default to 3600 seconds for the polling interval and 86400 seconds for sync interval.

3. Also as part of init, the daemon would reconcile the `STATE_DB`, a JSON file on disk and the current parsed information to calculate the cumulative values of fields that are subject to reset upon reboot. More on this is detailed in section [2.4.4](#244-accounting-for-reboots-and-unintended-powercycles) below.

4. After initialization, the daemon will gather static information utilizing S.M.A.R.T capabilities through instantiated class objects such as SsdUtil and EmmcUtil. This information will be subsequently updated in the `STATE_DB`.

5. The daemon would parse dynamic attributes also utilizing S.M.A.R.T capabilities via the corresponding class member functions, and update the `STATE_DB` per the preset frequency.

**NOTE:** The design requires a concurrent PR where EmmcUtil, SsdUtil classes are enhanced to gather Disk and FS IO Read/Write stats and Reserved Blocks information as detailed in section [2.4.1 below](#241-ssdbase-api-additions).
**NOTE:**
- The design requires a concurrent PR where EmmcUtil, SsdUtil classes are enhanced to gather Disk and FS IO Read/Write stats and Reserved Blocks information as detailed in section [2.4.1 below](#241-ssdbase-api-additions).
- Modifying the configuration intervals will only be applied in the subsequent cycle. Should immediate implementation be desired by the user, a configuration reload and daemon restart would be necessary.

This is detailed in the sequence diagram below:

Expand Down