The last few days I've been thinking about a building a system that would allow, effectively, a file-system to be created using excess space on many different machines. Managing policies about how many redundant copies would allow, effectively, RAID, to protect against machine or drive failures. Doing RAID-5 would be tricky, but doing RAID-1 would be very easy.
I imagine using extra space on a number of different machines, say in an office or in your house, to make a large virtual drive. Very much like what Google does for their Google File System, but on the cheap.
I figure it probably wouldn't be too bad if there were a single "master" which kept the file-system information and what systems held which files, and the storage systems were fairly stupid and would just store files and enforce file-system size limits. My thought was to have a first cut which would use a CGI on the storage systems for access, with an API of "get", "put", and "delete". I imagine that you would tell the system the size of the file when you do a "put", and it could reject the request if there were insufficient space.
Obviously, backends could also use FTP, SSH, DAV or other protocols.
I imagine the master system have a database of files and what servers have a particular file. It would also implement policies to ensure that, for example, 2 copies of the file exist, or that one copy exists at your east-coast office and one at the west-coast office. If a system went down, it could adjust replicate files to ensure that the storage policies were retained.
Ideally, you'd want to the master information not to be a single point of failure, but allowing for distributed updates among several masters would complicate the system quite dramatically. Using "spread" to distribute the master data to multiple machines could work, with a little complication. Or, periodic checkpoints of the data with regular incremental updates would be easy.
If the CGI were extended to include an "update" command that would append a changelog, one could use the normal "put" to save meta-data using the same mechanisms and policies for replication. Say, file inode 0 would be reserved for the meta-data and 1 would be reserved for the changelog?
Part of the reason for trying to keep it so simple is that I know I wouldn't have much time to develop such a thing. So, it needs to be as simple as possible for the first version.
Then, of course, I realized that I don't really have time to implement this. Also, we don't really have enough machines that are up on a regular basis to really make use of this at either home or the office. So, it wouldn't really be something I'd use regularly. It's more just an interesting idea.
Some of these ideas are inspired by memcached. Memcached is a package which uses RAM from one or more systems, reachable via the net, to cache objects or request results. You can use RAM from many different machines to act like a large memory cache on a single machine or a cluster of machines.comments powered by Disqus