[CAS] Add OnDiskGraphDB and OnDiskKeyValueDB #114102
Merged
Conversation
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 was referenced Oct 29, 2024
cachemeifyoucan
changed the base branch from
users/cachemeifyoucan/spr/main.cas-add-ondiskgraphdb-and-ondiskkeyvaluedb
to
main
cachemeifyoucan
force-pushed
the
users/cachemeifyoucan/spr/cas-add-ondiskgraphdb-and-ondiskkeyvaluedb
branch
from
e980f34 to
c497eeb
Compare
cachemeifyoucan
added a commit
that referenced
this pull request
Oct 7, 2025
Add OnDiskGraphDB and OnDiskKeyValueDB that can be used to implement ObjectStore and ActionCache respectively. Those are on-disk persistent storage that build upon OnDiskTrieHashMap and implements key functions that are required by LLVMCAS interfaces. This abstraction layer defines how the objects are hashed and stored on disk. OnDiskKeyValueDB is a basic OnDiskTrieHashMap while OnDiskGraphDB also defines: * How objects of various size are store on disk and are referenced by the trie nodes. * How to store the references from one stored object to another object that is referenced. In addition to basic APIs for ObjectStore and ActionCache, other advances database configuration features can be implemented in this layer without exposing to the users of the LLVMCAS interface. For example, OnDiskGraphDB has a faulty in function to fetch data from an upstream OnDiskGraphDB if the data is missing. Reviewers: Pull Request: #114102
|
✅ With the latest revision this PR passed the C/C++ code formatter. |
Add OnDiskGraphDB and OnDiskKeyValueDB that can be used to implement ObjectStore and ActionCache respectively. Those are on-disk persistent storage that build upon OnDiskTrieHashMap and implements key functions that are required by LLVMCAS interfaces. This abstraction layer defines how the objects are hashed and stored on disk. OnDiskKeyValueDB is a basic OnDiskTrieHashMap while OnDiskGraphDB also defines: * How objects of various size are store on disk and are referenced by the trie nodes. * How to store the references from one stored object to another object that is referenced. In addition to basic APIs for ObjectStore and ActionCache, other advances database configuration features can be implemented in this layer without exposing to the users of the LLVMCAS interface. For example, OnDiskGraphDB has a faulty in function to fetch data from an upstream OnDiskGraphDB if the data is missing. Reviewers: Pull Request: #114102
cachemeifyoucan
force-pushed
the
users/cachemeifyoucan/spr/cas-add-ondiskgraphdb-and-ondiskkeyvaluedb
branch
from
a2bb4e4 to
e2d20f8
Compare
Created using spr 1.3.7
cachemeifyoucan
requested review from
adrian-prantl,
aganea,
bogner and
ilovepi
Created using spr 1.3.7
Created using spr 1.3.7
Created using spr 1.3.7
Created using spr 1.3.7
| return InternalRef(Offset.get()); | ||
| } | ||
|
|
||
| friend bool operator==(InternalRef LHS, InternalRef RHS) { |
Collaborator
There was a problem hiding this comment.
out of curiosity: Can modern C++ = default this since there is only one data member?
Collaborator
Author
There was a problem hiding this comment.
This is c++20? I don't think we are there yet.
llvm/lib/CAS/OnDiskGraphDB.cpp
Outdated
|
|
||
| using StandaloneDataMapTy = StandaloneDataMap<16>; | ||
|
|
||
| struct InternalHandle { |
Collaborator
There was a problem hiding this comment.
Comment that explains what the "Internal" part of the name means?
Collaborator
Author
There was a problem hiding this comment.
I think this class doesn't provide much value in terms of adding readability. It is basically providing some helper function when decoding ObjectHandle. I can just fold everything into ObjectHandle while not exposing the detailed encoding scheme in the header. Removing InternalHandle.
Created using spr 1.3.7
Created using spr 1.3.7
adrian-prantl
approved these changes
Oct 16, 2025
ilovepi
approved these changes
Oct 20, 2025
Created using spr 1.3.7
Collaborator
Author
|
AArch64 bot failure due to AWS outage. Otherwise, don't see any problem. Merging. |
cachemeifyoucan
deleted the
users/cachemeifyoucan/spr/cas-add-ondiskgraphdb-and-ondiskkeyvaluedb
branch
Collaborator
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/169/builds/16197 Here is the relevant piece of the build log for the reference |
Contributor
|
This broke the MSAN bot. Please fix forward or revert if you need extra time |
Collaborator
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/76/builds/13253 Here is the relevant piece of the build log for the reference |
Collaborator
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/14/builds/4508 Here is the relevant piece of the build log for the reference |
Collaborator
Author
Sorry didn't see the MSAN bot. The error is weird maybe due to how |
cachemeifyoucan
added a commit
that referenced
this pull request
Oct 21, 2025
Contributor
#164457 landed in https://lab.llvm.org/buildbot/#/builders/164/builds/14720 but the test ( |
Collaborator
Author
Attempt 2 here: #164493 I didn't figure out the real reason of failure last time. It was due to not all the fields in |
Contributor
Thanks for the quick fix! |
nico
reviewed
Oct 22, 2025
| OnDiskKeyValueDBTest.cpp | ||
| OnDiskTrieRawHashMapTest.cpp | ||
| ProgramTest.cpp | ||
| ) |
Contributor
There was a problem hiding this comment.
I think most other places unconditionally include tests for conditional features and then ifdef out all the test code based on what's in config.h. Any reason not to do that here too?
Collaborator
Author
There was a problem hiding this comment.
I think it is cleaner this way than #ifdef the entire file out for those files. I can switch back to old ways if that is preferred.
I guess the other solution is put all of those under one test fixture and GTEST_SKIP() in Setup() if the build configuration is different.
Contributor
|
The test cases introduced here are failing in our CI on Red Hat Enterprise Linux 10, even last night despite all of those corrections merged later. This is the list of the systems on which these tests do .not. fail:
|
Contributor
|
The error log on RHEL10: |
Collaborator
Author
|
@pawosm-arm what is your target triple for those systems? What is the file system format? Do you have ways to reproduce it like from a docker image? |
Collaborator
Author
|
We have down stream CI running on Ubuntu and do not observe such errors. Let me know how can I help to fix it (or figure out some limitations). |
Contributor
It's the same as in Ubuntu, and as in the previous versions of RHEL: The filesystem is a standard ext4, and our building method is publicly visible: https://github.com/arm/arm-toolchain/blob/arm-software/arm-software/linux/build.sh (https://github.com/arm/arm-toolchain/blob/arm-software/arm-software/linux/build.sh-HOWTO.md for more details) |
Collaborator
Author
That is weird. I have trouble to get a RHEL10 container to build llvm. The error looks like some difference in file system memory mapping but it is hard to say without reproducing it. Let me know what you want to do in the next step. This is unit-test so we can disable that for now if we have a good macro to guard it against. |
Collaborator
Author
|
I manage to build inside a container but I am not able to reproduce: |
Contributor
That is extremely concerning. This test might have exposed something serious which have a potential to haunt the userspace programs doing specific or otherwise extensive filesystem I/O. |
Contributor
I need to obtain some more knowledge from our devops, every single detail that could make any difference even the slightest one that they may consider insignificant that could result in this unexpected difference in file system memory mapping. Also, could you write some higher level explanation what is the purpose of the code (and the test) that's failing? Maybe this could give them a hint where to look at... |
Collaborator
Author
There is an error message |
Contributor
A naïve question: could filesystem size affect that? or lack of free space? |
Collaborator
Author
|
I would expect running out of space will trigger a different error, and this error also happens on the read only side. Highly unlikely but I can't say for sure |
Contributor
|
Good news is that I've managed to reproduce it manually, outside of our CI, which means the problem isn't of CI-magical class: The bad news, I still don't know what the root cause could be. |
Collaborator
Author
|
Is this deterministically failing? Is there anyway we can figure out a way to reproduce it myself? |
Contributor
|
Trouble is, there is nothing unusual in the docker image I've tried: https://catalog.redhat.com/en/software/containers/ubi10/ubi/66f2b46b122803e4937d11ae#packages I've also managed to reproduce it again, on a much simpler AArch64 machine, so it's not a case of using a sophisticated hardware. Have you got a smaller piece of code that does the same thing so I could compile and run it in there? Could it be a glibc bug? |
Collaborator
Author
|
Oh, I can reproduce now. It seems only when using Looks like a corrupted data record somehow. |
Contributor
Makes sense, notice that on us it happens as we're testing the bootstrap compiler, which has been built with gcc/g++. |
Collaborator
Author
|
I don't know if it is a |
Collaborator
Author
|
I can't see any obvious logic mistakes in the code. I haven't dig too deep but it seems |
Lukacma
pushed a commit
to Lukacma/llvm-project
that referenced
this pull request
Oct 29, 2025
Add OnDiskGraphDB and OnDiskKeyValueDB that can be used to implement ObjectStore and ActionCache respectively. Those are on-disk persistent storage that build upon OnDiskTrieHashMap and implements key functions that are required by LLVMCAS interfaces. This abstraction layer defines how the objects are hashed and stored on disk. OnDiskKeyValueDB is a basic OnDiskTrieHashMap while OnDiskGraphDB also defines: * How objects of various size are store on disk and are referenced by the trie nodes. * How to store the references from one stored object to another object that is referenced. In addition to basic APIs for ObjectStore and ActionCache, other advances database configuration features can be implemented in this layer without exposing to the users of the LLVMCAS interface. For example, OnDiskGraphDB has a faulty in function to fetch data from an upstream OnDiskGraphDB if the data is missing.
Lukacma
pushed a commit
to Lukacma/llvm-project
that referenced
this pull request
Oct 29, 2025
Fix MSAN failure and expensive test failure.
aokblast
pushed a commit
to aokblast/llvm-project
that referenced
this pull request
Oct 30, 2025
Add OnDiskGraphDB and OnDiskKeyValueDB that can be used to implement ObjectStore and ActionCache respectively. Those are on-disk persistent storage that build upon OnDiskTrieHashMap and implements key functions that are required by LLVMCAS interfaces. This abstraction layer defines how the objects are hashed and stored on disk. OnDiskKeyValueDB is a basic OnDiskTrieHashMap while OnDiskGraphDB also defines: * How objects of various size are store on disk and are referenced by the trie nodes. * How to store the references from one stored object to another object that is referenced. In addition to basic APIs for ObjectStore and ActionCache, other advances database configuration features can be implemented in this layer without exposing to the users of the LLVMCAS interface. For example, OnDiskGraphDB has a faulty in function to fetch data from an upstream OnDiskGraphDB if the data is missing.
aokblast
pushed a commit
to aokblast/llvm-project
that referenced
this pull request
Oct 30, 2025
Fix MSAN failure and expensive test failure.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Add OnDiskGraphDB and OnDiskKeyValueDB that can be used to implement
ObjectStore and ActionCache respectively. Those are on-disk persistent
storage that build upon OnDiskTrieHashMap and implements key functions
that are required by LLVMCAS interfaces.
This abstraction layer defines how the objects are hashed and stored on
disk. OnDiskKeyValueDB is a basic OnDiskTrieHashMap while OnDiskGraphDB
also defines:
the trie nodes.
that is referenced.
In addition to basic APIs for ObjectStore and ActionCache, other
advances database configuration features can be implemented in this
layer without exposing to the users of the LLVMCAS interface. For
example, OnDiskGraphDB has a faulty in function to fetch data from an
upstream OnDiskGraphDB if the data is missing.