Distributed File System
A simple yet functional distributed file system implementation inspired by a CMU course project. The system features a centralized Naming Server architecture with distributed Storage Servers, supporting file replication and lock-based consistency.
ποΈ Architecture
Naming Server
- Acts as the central coordinator between clients and storage servers
- Manages file locations and lock distribution
- Single instance running at any time
- Handles server registration and file directory updates
Storage Servers
- Multiple instances can run simultaneously
- Register with Naming Server on startup
- Maintain local file directories
- Support file replication and consistency mechanisms
π Lock Management
The system implements two types of locks for file access:
- Shared Lock: Required for read operations
- Exclusive Lock: Required for write operations
Note: Due to architectural constraints, shared locks are treated as write operations, and exclusive locks are treated as read operations at the implementation level.
π¦ Features
Automatic Replication
- New replicas are created after every 20 shared locks on a file
- Replicas are distributed across available servers
- Ensures non-blocking access for multiple clients
Consistency Management
- Exclusive lock requests trigger replica consolidation
- Maintains single source of truth for write operations
- Automatic conflict resolution during server registration
π Getting Started
Prerequisites
- Go runtime environment
- Available network ports for services
- Storage space for file systems
Starting the Naming Server
Navigate to the naming
directory and run:
go run . <Client_Service_Port> <Slave_Registration_Port>
Example:
go run . 8080 8081
Starting a Storage Server
Navigate to the storage
directory and run:
go run . <Client_Service_Port> <Command_Port> <Registration_Port> <Storage_Directory> <Naming server ip>
Example:
go run . 9090 9091 8081 storage1 localhost
π‘ Implementation Notes
Storage Directory Handling
- Automatically created if it doesn't exist
- Preserves existing contents if directory is present
- Handles file conflicts during registration
Client Expectations
- Clients must request appropriate locks before file operations
- Locks should be released after operations complete
- Cooperative access model is assumed
π System Assumptions
-
Clients follow the locking protocol:
- Acquire appropriate locks before operations
- Release locks after completing operations
- Use shared locks for reads and exclusive locks for writes
-
File Replication:
- System maintains consistency across replicas
- Latest version access is guaranteed
- Non-blocking operations during normal usage
π Technical Details
Replication Mechanism
- Triggered after 20 shared locks
- Distributed across available servers
- Automatic cleanup during exclusive access
Consistency Protocol
- Single-writer, multiple-reader model
- Automatic conflict resolution
- Replica consolidation during writes
π€ Contributing
Feel free to submit issues and enhancement requests.
π Acknowledgments
This project is inspired by a CMU course project. For detailed project requirements, refer to the original course materials.