robojeb / agfs

AgFS is a union mount style filesystem designed to allow easy access for users to remote file locations while still allowing server maintainers to keep control over who has access to what part of the file tree.

AgFS programs

AgFS has three distinct programs with the following options.

• agfs [-i instance] mount point
• agfsd [-p port]
• agfs-keygen dns-name/ipaddr port user mount key-filename

Storage locations for AfFS data

Server

The server stores all generated keys and the key mapping file in /var/lib/agfs. Keys are generated through the agfs-keygen program and are automatically put in key folder and appended to the key mapping file.

Client

The client stores its keys and its instance definitions in ~/.agfs/. Keys must be manually placed by the user after being recieved from a server administrator. Users may define instances to limit what set of keys get used.

agfs's Issues

Possibly write the truncate function so that vim will work

Currently, vim pulls all file data into a buffer and then truncates the file to 0 and rewrites all data within the file. Thus, to benefit our presentation on Tuesday I think we should write truncate.

Modify the code that writes the server and client keys

Currently, the code that writes the keys to the server/reads from the client requires keys of a specific size. I have just written a lovely function for writing/reading c strings of arbitrary size to/from a socket file descriptor. We should migrate this code to use the new IO wrapper to allow for a more robust key authorization routine.

Need to check Quota's/FS free space on remote servers

In order to implement load balancing writes we will need to get quota information from servers. We should look at the available file system space if a server does not have a quota for the user bound to the current AgFS instance.

agfs-keygen needs to specify port

agfs-keygen does not have a port argument. This is fine under the current situation if all agfs-servers listen on the same port but if we allow servers to listen on different ports we will need to specify that port in the key-file so the client can successfully connect.

Implement Read

Now that we can read directories and we can get file metadata, we should write agfs_read so that we can get data from the remote server.

I am considering sending a flag that states whether or not there is more data after the current read buffer (in case the read cannot read all of the file data into the stream). It also appears that read takes in an ssize_t and returns an ssize_t which are both signed long ints (most likely signed 64 bit integers). We might want to consider using this to our advantage.

Make use of the fuse_file_info struct passed in to the open function

We should begin using the fuse_file_info struct to keep track of which servers have open files. We also need to keep a list of all open files on the client and on the server so that way the server can close all connections if the client disconnects, and so that we can remove the files from inactive servers on the client side.

Write the write function for the fuse client

The write function should be able to accept ambiguated or disambiguated file names. It should allow the user to write to the associated file any arbitrary number of bytes.

Parallelize AgFS fuse file system calls

Currently, each file system call will linearly search through the list of server connections checking each connection for a response. It would be so much faster if we could use threads (futures, processes, thread pools, etc.) to send each server request simultaneously and then read the answers back linearly. This should ensure that the file system calls are only as slow as the slowest server.

Write disambiguation code

We need to be able to disambiguate between files of the same name on different servers. This could be accomplished by placing all filenames into a map as keys, with a vector of server names as the value. If a vector has only one server we do nothing to the path, else we need to append on our special disambiguation sequence.

I think that the sequence will look something like:
{:server-name:}

Thus a full path would look like:
/home/mark/awesome_file_names_mark.txt{:viki.st.hmc.edu:}

This code should probably be wrapper functions or at least a class that will handle disambiguation for us (it takes in filename and server pairs).