e6f2d84736
Deadlock occurs when `getActivate` function opens new blobovnicza and that invokes evict in LRU cache of open blobovniczas. `getActivate` makes `activeMtx.Lock()` and then cache evict makes `activeMtx.RLock()` and deadlock happens. Fix contains two steps: - add separate mutex to open blobovniczas (1), - split single Lock outside of `updateAndGet` (2). As for the (1) `bbolt.Open()` locks when it tries to open the same file from two threads. So separate mutex will prevent that. As for the (2) `updateAndGet` function contains from two parts. At first it checks if required blobovnicza is ready and it returns it. In this case we can use the simple RLock. But then there is an option when we should open new blobovnicza and update map of active blobovniczas. In this case we call `openBlobovnicza` without activeMtx lock. Cache evict happens there and it won't cause deadlock. Then we lock activeMtx to update the map of active blobovniczas. Concurrency can happen there. However `openBlobovnicza` will not open the same blobovnicza twice, so we can make one more check if opened blobovnicza was activated while thread was locked in activeMtx. If so, then return active blobovnicza, else finish activation. Signed-off-by: Alex Vanin <alexey@nspcc.ru> |
||
|---|---|---|
| .github | ||
| cmd | ||
| docs | ||
| misc | ||
| pkg | ||
| .dockerignore | ||
| .gitattributes | ||
| .gitignore | ||
| .golangci.yml | ||
| CHANGELOG.md | ||
| CONTRIBUTING.md | ||
| CREDITS.md | ||
| Dockerfile.cli | ||
| Dockerfile.ir | ||
| Dockerfile.storage | ||
| go.mod | ||
| go.sum | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
NeoFS is a decentralized distributed object storage integrated with the NEO Blockchain.
Overview
NeoFS Nodes are organized in peer-to-peer network that takes care of storing and distributing user's data. Any Neo user may participate in the network and get paid for providing storage resources to other users or store his data in NeoFS and pay a competitive price for it.
Users can reliably store object data in the NeoFS network and have a transparent data placement process due to decentralized architecture and flexible storage policies. Each node is responsible for executing the storage policies that the users select for geographical location, reliability level, number of nodes, type of disks, capacity, etc. Thus, NeoFS gives full control over data to users.
Deep Neo Blockchain integration allows NeoFS to be used by dApp directly from NeoVM on the Smart Contract code level. This way dApps are not limited to on-chain storage and can manipulate large amounts of data without paying a prohibitive price.
NeoFS has native gRPC API and popular protocol gates such as AWS S3, HTTP, FUSE and sFTP allowing developers to easily integrate applications without rewriting their code.
Contributing
Feel free to contribute to this project after reading the contributing guidelines.
Before starting to work on a certain topic, create an new issue first, describing the feature/topic you are going to implement.
Credits
NeoFS is maintained by NeoSPCC with the help and contributions from community members.
Please see CREDITS for details.