Mini-FAT Project, stage 2

by: burt rosenberg
at: university of miami
date: nov 2016
NAME
    minifat
    
SYNOPSIS	
    minifat -d _directory_ [-cv] _virtual-disk_
    
DESCRIPTION
    Uses FUSE to attach the file system implemented in the minifat code to the
    named directory, with the virtual data file _virtual-disk_.

OPTIONS
   The -d option is manditory.

    -d The directory to attach.
    -c create the file _virtual-disk_, or zero if already exists.
    -v verbose output
        
    When zeroing the virtual disk, or running without the -c option,
    verify that the _virtual-disk_ is 1,048,576 bytes exactly, and begins
    with the character sequence "MINIFAT 1.0\0".
    
HISTORY
    FAT/FUSE was introduced in CSC521 2006-2007; MiniFat was introduced 2012-2014; 
    further simplified in this project.
    
BUGS
    The -d option is mandatory. Future versions will make the option an argument.
    The minifat program might not receive a well formated _virtual-disk_. Only so
    much is feasible in the context of a class assignment to make minifat fail 
    gracefully when _virtual-disk_ is not well formated.

Part two requirements

The project is divided into a stage one, and stage two. Stage one was described here.

In part two you introduce files, and for extra credit, subdirectories. Implement the read and write (as well as truncate, etc.) Fuse operations on files. You must return the correct file size by stat. You should be able to write and read at various locations, not just appending to the file. Zero fill the file if the write skips over bytes.

You must also implement the remove file, including reclaiming the clusters.

Create folder proj6 for this project, starting from your code in folder proj5. The class directory has a proj6 which has a suggestion of a more complicated file layout. The files fuseops.c and mf-utils.c separate code from minifat.c.

Previous projects created separate files in order to demonstrate the difference between writing code and using code: the code inside of one file could could have various interdependencies, but between files, all that matters is the interface stated by the dot-h files. This project, however, separates code into files because the code will be too long to allow me to recommend putting it all into a single file: expect over 1,000 lines of code to complete stage 2.

Extra credit

For extra credit, once files are working, implement subdirectories. Without this option, the root directory can have entries with are marked directories, but they are not functional. To implement subdirectories you have to implement search paths and the expanding of the cluster chain for directores.

Implementing subdirectories means implementing path searching. This will most likely be the most difficult part of the extra credit.

An empty diretory should have exactly one cluster in its chain, so is of size 1024, and you can simulate the "." and ".." entries, for the benefit of the caller of Fuse, without actually representing them in a MiniFat directory.

If you wish, create a proj6-ec and continue your work on proj6 to implement the extra credit in proj6-ec.

Hints

The program screen allows you to run multiple windows. This allows minifat to run in the foreground so you can see diagnostic output while in another window you test the fuse mounted directory or hexdump the virtual disk, to see what is going on. You can also log in multiple times using ssh, but this means setting up an ssh demon on your host and possibly modifying your networking options.

To use screen type "screen" and accept with the space bar. All screen commands start with control-A.

When all created screens are killed, screen exits. Screen is a bit strange in that after running screen there isn't a real change that you can see. Type "screen" then ^A c to create a new screen. Then use ^A ^A to flip back and forth between the screens. This will give one screen to run minifat in the foreground and observe it diagnostics message, and another screen to exercise the file system, running ls and so forth.

See: www.gnu.org, screen.

The truncate fuseop is a good starting point for stage 2. It is a subtask to writing, it can be written and tested in isolation of any other operation including write, and it exercises much of the algorithmic complications of stage 2.

Truncate can either reduce the size of a file, or increase it. To reduce it, you should release and free unneeded clusters. To increase, you must claim and link new clusters, zero filling both the new clusters, and the slack space that might exist in the cluster at the old end of the cluster chain.

The operations read and write are probably best co-developed, although you could develop a simplified write first using hexdump to watch the effects directly in the virtual disk. Simplified versions of read and write to consider: at first ignore offset and always read and write starting at offset 0; only consider files of length 1024 or less. Once these are running you can start to implement further behavior.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

author: burton rosenberg
created: 17 nov 2016
update: 24 nov 2016