-
Notifications
You must be signed in to change notification settings - Fork 340
DAOS-16964 ddb: read-only mode requires enabling Copy-on-Write for... #17533
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.
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
Open
janekmi
wants to merge
7
commits into
master
Choose a base branch
from
janekmi/DAOS-16964-read-only-cow
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+138
−89
Open
Changes from all commits
Commits
Show all changes
7 commits
Select commit
Hold shift + click to select a range
e6e97dd
DAOS-16964 ddb: read-only mode requires enabling Copy-on-Write for PM…
janekmi 7baa0b6
DAOS-16964 ddb: cleanup the interface + add doc
janekmi 0759ada
Merge remote-tracking branch 'origin/master' into janekmi/DAOS-16964-…
janekmi fd9ea1f
DAOS-16964 ddb: adjust a comment
janekmi 5e28aaf
DAOS-16964 ddb: add a read-only vs write mode test
janekmi 1c59b82
DAOS-16964 vos: remove the mlock() workaround
janekmi 1de73f2
DAOS-16964 vos: remove the mlock() workaround (fix)
janekmi File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If new private copy is allocated, then when open the vos pool again, the operation (read/write) will work against the original one or the new copy?
On the other hand, under non-interactive mode, many ddb sub-commands will open the vos pool implicitly as read-only, such as
ddb ls. If it is repeated for a lot of times (for different items), will that cause some trouble for copy-on-write? Under extreme case, willddb lsmay fail because of ENOSPC?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a volatile copy of modified pages in RAM. These pages are freed once you close the pool / call
munmap().Please see
mmap()andMAP_PRIVATEfor details.If it is truly read-only I assume no changes will be made no matter the number of items being processed. So, I expect after startup, when a few copied pages will be allocated (for various PMEMOBJ purposes), the memory consumption in this department ought to be flat.
If, despite of the assumption of not making any changes to the pool, VOS actually makes writes to the pool when the user (DDB) requests merely to read the data, the memory consumption will continue to grow. The final signal would be ENOMEM.
If the latter is the case I would argue we should rethink are even able to provide a read-only mode.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure for this. It is better to make some test with you patch, such as repeatedly
ddb ls.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not know how the implicit modification will be triggered when open the vos-pool and what is the potential side-effect. According to your description in DAOS-16964, both the vos file time stamp and some other metadata are changed.
Will that potentially damage the vos-pool? If it is harmful, does it means even if we did not run
ddb, related risk still be there when DAOS engine normally opens the vos-pool? Otherwise, if it is harmless, can we ignore such implicit modification to avoid CoW trouble?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. It can. You can imagine e.g. the PMEMOBJ ulog is corrupted. If we have bad luck PMEMOBJ may apply these malicious changes and further mangle the VOS pool contents. Which may prevents us from finding the root cause of whatever problem we are trying to pinpoint.
Yes. At the moment opening the VOS pool always does the same things underneath. No matter whether the open is supervised by DDB or
daos_engine.It looks like it is not harmless in general. But regardless I think CoW is worth the hassle because we need a read-only mode in my opinion. Otherwise, DDB is not really a debug tool since we cannot control what it does to the VOS file.
daos_engine