https://github.com/cberner/depsrs-bug

https://github.com/cberner/depsrs-bug

Last synced: about 2 months ago
JSON representation

• Host: GitHub
• URL: https://github.com/cberner/depsrs-bug
• Owner: cberner
• License: apache-2.0
• Created: 2021-06-27T18:10:19.000Z (over 3 years ago)
• Default Branch: master
• Last Pushed: 2021-06-28T01:01:41.000Z (over 3 years ago)
• Last Synced: 2024-10-15T01:09:12.782Z (3 months ago)
• Language: Rust
• Size: 98.6 KB
• Stars: 0
• Watchers: 3
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md
  • License: LICENSE

Awesome Lists containing this project

README

        
# FleetFS

[![Build Status](https://travis-ci.com/fleetfs/fleetfs.svg?branch=master)](https://travis-ci.com/fleetfs/fleetfs)

[![Crates](https://img.shields.io/crates/v/fleetfs.svg)](https://crates.io/crates/fleetfs)

[![Documentation](https://docs.rs/fleetfs/badge.svg)](https://docs.rs/fleetfs)

[![dependency status](https://deps.rs/repo/github/fleetfs/fleetfs/status.svg)](https://deps.rs/repo/github/fleetfs/fleetfs)

FleetFS distributed filesystem

## Development

* `apt install flatbuffers-compiler` (https://github.com/google/flatbuffers)

* rustup component add rustfmt

* rustup component add clippy

## Status

Very very alpha. Expect FleetFS to eat your data :)

## Design decisions

* Clients only need to talk to a single node

  * Context: There is significant overhead in opening TCP connections, so we want the client to keep its

  connections open. Therefore, the client shouldn't make on-demand connections to every storage node in

  the cluster.

  * Cons: doubles network traffic inside FleetFS cluster, as nodes have to proxy traffic reading/writing

  to other nodes

  * Pros: better scalability, as client connection is handled by a single node. Also simplifies client code

* Clients are trusted to make permission checks

  * Context: FleetFS has no access to a central user store, so has to trust the user ids sent by the client

  * Cons: security relies on the client

  * Pros: client doesn't have to send exhaustive list of groups that user is part of to make permission checks

* Sharding design:

  * "Raft group" (or rgroup): a subset of storage nodes participating in a raft consensus group.

  The cluster consists of multiple Raft groups, and a single node may be part of multiple groups.

  * An inode is stored on a single Raft group, and inodes are sharded among groups, by id.

  * (TODO) "Redundant block" (or rblock) is a block of data stored in a single Raft group.

  A file's contents is composed of multiple rblocks, on one or more Raft groups.

## License

Licensed under

 * Apache License, Version 2.0 ([LICENSE](LICENSE) or http://www.apache.org/licenses/LICENSE-2.0)

### Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted

for inclusion in the work by you shall be licensed as above, without any

additional terms or conditions.