Shrink writecache #1298

Merged
fyrchik merged 1 commit from dstepanov-yadro/frostfs-node:feat/drop_writecache_bolt_db into master 2024-09-04 19:51:10 +00:00
  • frostfs-cli control writecache seal supports restore-mode flag to restore writecache's mode to current mode after sealing (writecache seal assumes flush and move to disabled mode)
  • frostfs-cli control writecache seal supports shrink flag to recreate db after flush to reduce disk size used by bbolt database
* `frostfs-cli control writecache seal` supports `restore-mode` flag to restore writecache's mode to current mode after sealing (`writecache seal` assumes flush and move to disabled mode) * `frostfs-cli control writecache seal` supports `shrink` flag to recreate db after flush to reduce disk size used by bbolt database
dstepanov-yadro force-pushed feat/drop_writecache_bolt_db from cee87c13ca to ba50e46c30 2024-08-06 13:56:05 +00:00 Compare
dstepanov-yadro requested review from storage-core-committers 2024-08-06 14:41:12 +00:00
dstepanov-yadro requested review from storage-core-developers 2024-08-06 14:41:12 +00:00
dstepanov-yadro force-pushed feat/drop_writecache_bolt_db from ba50e46c30 to ef2cc1df3b 2024-08-07 08:20:36 +00:00 Compare
acid-ant approved these changes 2024-08-07 10:16:17 +00:00
achuprov approved these changes 2024-08-07 14:28:53 +00:00
aarifullin approved these changes 2024-08-08 08:30:28 +00:00
fyrchik reviewed 2024-08-08 09:50:02 +00:00
@ -68,6 +77,8 @@ func initControlShardsWritecacheCmd() {
ff.StringSlice(shardIDFlag, nil, "List of shard IDs in base58 encoding")
ff.Bool(shardAllFlag, false, "Process all shards")
ff.Bool(ignoreErrorsFlag, true, "Skip invalid/unreadable objects")
ff.Bool(restoreModeFlag, false, "Restore writecache's mode after sealing")
Owner

We replaced flush-cache with seal specifically to denote it's meaning in the name.
With this flag it is no longer seal.
Why is it neccessary to have this flag?

We replaced `flush-cache` with `seal` specifically to denote it's meaning in the name. With this flag it is no longer `seal`. Why is it neccessary to have this flag?
Author
Member

It was the real case, when we needed to flush and recreate writecache's bbolt DB.
Agree, with this flag it looks like step back. But writecache seal will have async execution, so I decided to add this flag here.

It was the real case, when we needed to flush and recreate writecache's bbolt DB. Agree, with this flag it looks like step back. But `writecache seal` will have async execution, so I decided to add this flag here.
Owner

OK, I am too tired to argue.

The help message needs to be altered somehow

$ bin/frostfs-cli control shards writecache seal -h
Flush all the objects from the write-cache to the main storage and move the write-cache to the degraded read only mode: write-cache will be empty and no objects will be put in it.
OK, I am too tired to argue. The help message needs to be altered somehow ``` $ bin/frostfs-cli control shards writecache seal -h Flush all the objects from the write-cache to the main storage and move the write-cache to the degraded read only mode: write-cache will be empty and no objects will be put in it. ```
Author
Member

No need to argue. You asked a question, I answered it. If you do not agree with this decision, then tell me how to do it.

No need to argue. You asked a question, I answered it. If you do not agree with this decision, then tell me how to do it.
fyrchik marked this conversation as resolved
fyrchik approved these changes 2024-08-08 11:30:59 +00:00
@ -26,3 +29,3 @@
defer c.modeMtx.Unlock()
err := c.setMode(ctx, m, true)
err := c.setMode(ctx, m, true, false)
Owner

What about prm struct for this? true, false is indistinguishable from false, true
Or maybe bitmask flags.

What about `prm` struct for this? `true, false` is indistinguishable from `false, true` Or maybe bitmask flags.
Author
Member

Fixed

Fixed
fyrchik marked this conversation as resolved
@ -74,0 +88,4 @@
b := tx.Bucket(defaultBucket)
cs := b.Cursor()
k, v := cs.First()
empty = len(k) == 0 && len(v) == 0
Owner

b.Stats().KeyN?

`b.Stats().KeyN`?
Author
Member

Fixed

Fixed
fyrchik marked this conversation as resolved
@ -74,0 +100,4 @@
if empty {
err := os.Remove(filepath.Join(c.path, dbName))
if err != nil && !os.IsNotExist(err) {
return fmt.Errorf("failed to remove DB file: %w", err)
Owner

The function seems no longer idempotent because of this: if we retry, we will fail on c.db.View with ErrClosed

The function seems no longer idempotent because of this: if we retry, we will fail on `c.db.View` with `ErrClosed`
Author
Member

Good point. Fixed. Now assume already closed DB as non empty.

Good point. Fixed. Now assume already closed DB as non empty.
fyrchik marked this conversation as resolved
@ -657,1 +657,4 @@
bool ignore_errors = 2;
// If true, then writecache will be sealed, but mode will be restored to the current one.
bool restore_mode = 4;
Owner

Why not 3?

Why not 3?
Author
Member

3 is taken here #1284/files

3 is taken here https://git.frostfs.info/TrueCloudLab/frostfs-node/pulls/1284/files#diff-294a0e9758444ffdbca2b60b6f6f3184eddc155f
Owner

Next level conflict resolution, I must say!

Next level conflict resolution, I must say!
dstepanov-yadro force-pushed feat/drop_writecache_bolt_db from ef2cc1df3b to 36efccd862 2024-08-08 13:33:51 +00:00 Compare
fyrchik merged commit 36efccd862 into master 2024-08-09 06:28:34 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
5 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: TrueCloudLab/frostfs-node#1298
No description provided.