Building and evaluating a user-level file system using the FUSE interface

Goal: Building and evaluating a user-level file system using the FUSE interface **This is an undergraduate operating systems class project: Details: ** 1. Building a software disk with a read/write interface: int read(off_t offset,size_t length,byte[] buffer) and write(off_t offset, size_t length, byte[] buffer). You can use a regular file as your disk. However, reading/wring from/to this fake disk has to be in chunk of blocks meaning the length argument has to be the block size which is 8K now, and the offset argument has to be muliple of block size. 2. Build a file system on top of the disk that is similar to ext2 with the following characteristics: 1. fixed inode size of 64B 2. fixed block size of 8K 3. at least one level of indirection 3. Link the file system with the FUSE interface 4. Your file system should have the following functionalities: 1. create file/directory 2. list directory 3. read/write to file 4. statistics about the file/directory 5. Your file system doesn't have to support symbolic links 6. Your file system doesn't have to support multi-threading 7. Your file system must include a buffer cahe 8. Unlike ext2, you don't have to support multiple block groups, but you can just use one block group 9. You don't have to implement rename 10. Your system should have a tool like fsck for checking and repairing the integrity of the file system if uncleanly shutdown **Additional details are given in the "deliverables" section. Also I can be contacted for any questions that you may have. ** ## Deliverables **What you have to consider: ** 1. how to organize your inode: 1. how many indirect blocks you should have, 2. how big each pointer should be, 3. what fields are needed and what sizes they should have 2. is the indirect block model good? can you do better? 3. how do you do the translation between pathname and inode? 4. is the buffer cache helpful? **How to evaluate the file system: ** * micro benchmark: 1. how long it takes for file operations like create, read, write on average for a large number of operations, say 1000. * macro benchmark: 1. run an application or a set of applications and report the results. **Installing FUSE**: IMPORTANT: those who haven't built the fuse yet, please follow this: 1. download [login to view URL] 2. untar it 3. cd fuse-2.2.1 4. ./configure 5. make 6. make install 7. There is an *example* directory, which contains the fuse examples. It's built automatically when you do *make* at step 4. <!-- --> 1. *apt-get update* 2. *apt-get install libfuse2 libfuse-dev fuse-utils pkg-config fuse-source module-assistant* to install all the packages we need. * During the installation choose the default answers * When it asks for which interface to use for configuring packages choose dialog, choose medium for 'see only questions that are of what priority and higher' * When you see "Configuration file '/etc/modutils/aliases', choose the default option * Upgrade glibc when it asks for that * Restart the services when it asks for that Now we need to build the fuse module 1. *module-assistant prepare* to get all the tools we need for installation. It will pull down cpp,g++...., answer yes when it asks 2. *module-assistant build fuse-source* to build the module 3. *module-assistant install fuse-source* to install the module During apt-get update you may get a bunch or errors. That's because the site maybe down, so you can copy the [login to view URL] attachment here to /etc/apt/[login to view URL], I tried to get rid of as many broken links as possible. **Compiling and running example: ** * an example file is attached with this assignment * compile it using *gcc -Wall `pkg-config fuse --cflags --libs` fusexmp.c -o fusexmp* * run it using *./fusexmp /mnt/* where /mnt is the directory you mount the file system to. If you build your fuse from [login to view URL] file provide please do *export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/usr/local/lib* before running it because [login to view URL] is now it /usr/local/lib. * try it with a command like *ls /mnt* The example file system is the mirror of the current file system, starting from /, but now mount at /mnt. Be really **careful** when you write or make any modification to /mnt mount point after that because you're **modifying the real file system** as well. **Callbacks you need to implement:** You need to implement at least the following callbacks for your file system to work correctly 1. int (*getattr) (const char *, struct stat *); 2. int (*getdir) (const char *, fuse_dirh_t, fuse_dirfil_t); 3. int (*mknod) (const char *, mode_t, dev_t); 4. int (*mkdir) (const char *, mode_t); 5. int (*unlink) (const char *); 6. int (*rmdir) (const char *); 7. int (*open) (const char *, struct fuse_file_info *); 8. int (*read) (const char *, char *, size_t, off_t, struct fuse_file_info *); 9. int (*write) (const char *, const char *, size_t, off_t, struct fuse_file_info *); 10. int (*release) (const char *, struct fuse_file_info *); **Handin:** * all source files, README, Makefiles * report containing what you did, the difficulties you encountered, the design choices you made, graphs, figures, tables and analysis of the performance evaluation. Please include citations if you refer to other works. **Extra Credit for: ** * implementing multi-threading * implementing rename and symbolic links and the corresponding fuse api * implementing a journaling file system like ext3 **Grading** * 40% Report and evaluation * 20% Fuse integration * 40% File system implementation * you must complete the required part first for the extra credit part to be considered. The following also applies: 1) Complete and fully-functional working program(s) in executable form as well as complete source code of all work done. 2) Deliverables must be in ready-to-run condition, as follows (depending on the nature of the deliverables): a) For web sites or other server-side deliverables intended to only ever exist in one place in the Buyer's environment--Deliverables must be installed by the Seller in ready-to-run condition in the Buyer's environment. b) For all others including desktop software or software the buyer intends to distribute: A software installation package that will install the software in ready-to-run condition on the platform(s) specified in this bid request. 3) All deliverables will be considered "work made for hire" under U.S. Copyright law. Buyer will receive exclusive and complete copyrights to all work purchased. (No GPL, GNU, 3rd party components, etc. unless all copyright ramifications are explained AND AGREED TO by the buyer on the site per the coder's Seller Legal Agreement). ## Platform unix