-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Potential patent problem with golang-lru.ARCCache #6590
Comments
At the moment, this issue would only concern non-OSS forks of go-ipfs: https://www-03.ibm.com/press/us/en/pressrelease/7473.wss. Postgres appears to have had the same issue so they just switched to a slightly different algorithm: http://www.varlena.com/GeneralBits/96.php. We can probably just switch to the 2Q cache https://github.com/hashicorp/golang-lru/blob/master/2q.go. |
Due to patent concerns in closed-source downstream products: ipfs/kubo#6590
Simple fix: ipfs/go-ipfs-blockstore#20 |
good find @Stebalien, I was wondering whether this patent was in the OSS pool... 2Q looks nearly indistinguishable in general case performance from ARC based on the paper so this fix seems reasonable |
fixes #6590 (potential non-OSS patent issue)
fixes ipfs#6590 (potential non-OSS patent issue)
fixes ipfs#6590 (potential non-OSS patent issue)
fixes ipfs#6590 (potential non-OSS patent issue)
fixes ipfs#6590 (potential non-OSS patent issue)
fixes ipfs#6590 (potential non-OSS patent issue)
fixes ipfs#6590 (potential non-OSS patent issue)
## Describe your changes and provide context IRRC we had discussions around bumping the limit for the inter-block cache since 1k is pretty little for our volume of TXs per block. Im setting it to 100k to be the same as the BoundedCacheKv store While I was investigating the race condition issue in the LRU cache, I saw that several repos brought up concerns around using ArcCache in their code as it's been patented by IBM (and later sold to Intel) hashicorp/golang-lru#31 hashicorp/golang-lru#73 ipfs/kubo#6590 ipfs/go-ipfs-blockstore#20 Postgres and IPFS replaced it with 2Q, which based on the whitepaper should have the same performance as ARC. ## Testing performed to validate your change Deployed a LT cluster with these changes and saw no impact to consensus and the performance (with LT clients running) is similar ![image](https://user-images.githubusercontent.com/18161326/216499319-be5ae693-242f-453c-8073-414bf5f810bd.png)
## Describe your changes and provide context IRRC we had discussions around bumping the limit for the inter-block cache since 1k is pretty little for our volume of TXs per block. Im setting it to 100k to be the same as the BoundedCacheKv store While I was investigating the race condition issue in the LRU cache, I saw that several repos brought up concerns around using ArcCache in their code as it's been patented by IBM (and later sold to Intel) hashicorp/golang-lru#31 hashicorp/golang-lru#73 ipfs/kubo#6590 ipfs/go-ipfs-blockstore#20 Postgres and IPFS replaced it with 2Q, which based on the whitepaper should have the same performance as ARC. ## Testing performed to validate your change Deployed a LT cluster with these changes and saw no impact to consensus and the performance (with LT clients running) is similar ![image](https://user-images.githubusercontent.com/18161326/216499319-be5ae693-242f-453c-8073-414bf5f810bd.png)
Due to patent concerns in closed-source downstream products: ipfs/kubo#6590 This commit was moved from ipfs/go-ipfs-blockstore@82da4c4
Version information:
go-ipfs v0.4.22
Description:
I'm obviously not a lawyer and not even really versed in those kind of things, but golang-lru state that:
https://github.com/hashicorp/golang-lru/blob/master/doc.go#L16-L17
go-ipfs does use ARC, specifically through
go-ipfs-blockstore
. Would that be a problem?The text was updated successfully, but these errors were encountered: