1. SIMULATED UNIX FILE SYSTEM Implementation in C Tarek Youssef Bipanjit Sihra

2. About This Demo Method of organization Modifying the UNIX FS Implementation to meet our system specifications Simulated FS superblock Simulated FS files and directories Opening and closing files Demo of code Reference: The Design of the Unix Operating System By Maurice J. Bach Advanced Programming in the Unix Environment By W. Richard Stevens http://www.angelfire.com/myband/binusoman/Unix.htm

3. Structural Design of Simulated Unix File System The Super Block

4. Unix File System The arrangement of disk blocks in Unix is as shown in the figure below.

5. Unix File System The arrangement of disk blocks in Unix is as shown in the figure below. We don’t need a Boot Block

6. Unix File System Super Block The super block contains the following information, to keep track of the entire file system. Size of the file system Number of free blocks on the system A list of free blocks Index to next free block on the list Size of the inode list Number of free the inodes A list of free inodes Index to next free inode on the list Lock fields for free block and free inode lists Flag to indicate modification of super block

7. Unix File System Super Block Our Simulated File System is of fixed size. Size of the file system Number of free blocks on the system A list of free blocks Index to next free block on the list Size of the inode list Number of free inodes A list of free inodes Index to next free inode on the list Lock fields for free block and free inode lists Flag to indicate modification of super block

8. Unix File System Super Block Our Simulated File System runs only one process. Size of the file system Number of free blocks on the system A list of free blocks Index to next free block on the list Size of the inode list Number of free inodes A list of free inodes Index to next free inode on the list Lock fields for free block and free inode lists Flag to indicate modification of super block

9. Simulated File System Super Block

10. Unix File System Free Block List

11. Simulated File System Free Block List When a block gets allocated, the number stored in the element pointed by the index is freed (returning a number of a free block) then the index gets decremented. When a block is freed, the index is incremented, and the freed block number is inserted in the element pointed by the index. When the index reaches -1, no more free elements is available which signals an exhaustion in the free space on the file system.

12. Unix File System Free Inode List

13. Simulated File System Free Inode List When creating a file or a directory a unique number between 0 and 63 representing the I-node number is given to file. Whenever the file or directory is deleted that number is now free to be used for other files or directories The I-node index is used in a similar fashion to Free Block List, when the index reaches (-1), the system has exhausted the possible number of files it can take (even if free space is still available) and files or directories can no longer be allocated without first deleting one or more files.

14. Unix File System Inode List The I-node list is a list of inodes, which contains the following entries. Owner Type Last modified time Last accessed time Last inode modified time Access Permissions No of links to the file Size of the file Data blocks owned

15. Unix File System Inode List Most of those parameters is not needed in our small file system Owner Type Last modified time Last accessed time Last inode modified time Access Permissions No of links to the file Size of the file Data blocks owned

16. Unix File System Blocks Owned

18. Simulated File System Inode List

19. Super Block Implementation I-Node Structure struct sfs_inode { short int di_node; // I-Node number short intdi_type;//File type ( Directory Or File) sjort intd_size;// Actual file size short int di_nblocks; // Number of blocks actually used by the file short intdi_blocks[4];// the blocks owned by the file; }

20. Superblockio.c Methods short int sfs_write_super(); short int sfs_write_inode( sfs_inode_t ); short int sfs_read_inode( short int, sfs_inode_t* ); short int sfs_get_block(); short int sfs_free_block(short int); short int sfs_get_inode(); short int sfs_free_inode(short int);

21. Structural Design of Simulated Unix File System The Data Blocks (File And Directory Structures)

22. Files Regular files on the system can occupy any free data blocks on the system. The file size can range between 0, and 512 bytes maximum to satisfy the requirement of the project Although the file can have a size less than a full block, any file occupies at minimum 1 block, and increases by 1 block as its size exceeds maximum of block size (128 bytes ) The actual file size needed for I/O operations is stored in the file size field in the I-Node List corresponding to its I-Node number.

23. Directories

24. Directories The directory structure represents an ASCII file or directory name to I-node number lookup table. Each directory represents a number of records (max 64 representing the maximum number of files on the system). Each record is 8 bytes, and consists of 2 fields. The first field is the name field representing an ASCII name for the file or sub directory and is 6 bytes in length representing the maximum allowable file name length. The second field is the I- node number field and is 2 bytes number. Each directory contains 2 special ASCII representations. The first is the “.” which represents a link to itself (the I-node number points to itself). The second is the “..” which represents a link to the parent directory.

25. Representing a directory entry (The dentry structure) enum node_type {FILE_NODE, DIRECTORY_NODE, ROOT_NODE }; typedef enum node_type node_type_t; struct sfs_dentry; typedef struct sfs_dentry sfs_dentry_t; struct sfs_dentry { char d_iname[6]; // File/directory name Max 6 sfs_inode_t* d_inode; // I- Node associated with file name sfs_dentry_t* d_parent; // dentry object of parent directory }; struct sfs_directory_listing { char dl_name[6]; short dl_inode; }; typedef struct sfs_directory_listing sfs_directory_listing_t;

26. Locating a node (dentry)

27. Steps: step 1: Insure we have a '/' at the beginning of the path (we don't support relative path) Step 2: Insure the string is null terminated and is not impossibly long; step 3: Start with the root node step 4: If we are looking for the root node itself prepare its dentry structure and return it. step 5: find our first node name step 6: walk through the path, until we find our destination node step 7: before fetching the new node name in the current node we need to insure the current node is a directory (avoid /dir/file/dir) step 8: the current node becomes the parent node step 9: Assign the new node name we just got to the node_dentry step 10: Find the name in the parent's directory listings step 11: Find the and retrieve the inode associated with the directory listings step 12: find the next entry in the path if any

28. Creating a node Steps: step 1: IF FILE_NODE or DIRECTORY_NODE Insure unique file name step 2: allocate a new sfs_inode structure on the heap step 3: get a free i-node number step 4: get free blocks and assign the size step 5: set the type step 6: write a the inode data to the inode block step 7: Assign the new sfs_inode structure to the dentry object step 8: For newly created directories initialize the directory listings step 9: Creating a root node is done by step the end of step 8 step 10: update the parent with a link to the node step 11: update the parent's i-node size to reflect the the added node

29. Removing a node Steps: step 1: We can't remove a ROOT_NODE type step 2: We can't remove a DIRECTORY_NODE type that is not empty step 3: We should attempt to remove the parent's link first step 4: Modify the parent's inode decrementing the directory size by one step 5: Now attempt to free the data blocks assigned by the inode; step 6: Now attempt to free the inode itself

30. Fileoperations.c Methods short sfs_create_fs(); short sfs_create_node(node_type_t, sfs_dentry_t * ); short sfs_remove_node(sfs_dentry_t * node_dentry); short sfs_locate_node(char* path, sfs_dentry_t* node_dentry); short sfs_write_to_file (sfs_dentry_t* file_node, int start, int length, char* buffer); short sfs_read_from_file (sfs_dentry_t* file_node, int start, int length, char* buffer); short sfs_read_from_directory (sfs_dentry_t* directory_node, int offset, char* buffer); //Some Helper Functions short sfs_free_dentry_mem(sfs_dentry_t* dentry); short sfs_put_data_block(int blknum, char *buf); short sfs_get_data_block(int blknum, char *buf); short sfs_split_path (char* path, char* parent_path,char* node_name);

31. Opening and closing files File Control Block Structure struct sfs_fcb { shortfd; // File Descriptor Number short f_offset; // Current offset in file sfs_dentry_t* f_dentry; // Dentry object associated with FCB }; typedef struct sfs_fcb sfs_fcb_t; Per Proccess Open File Table struct ppoft { int is_init; // Insure we initialized PPOFT int open_files; // Number of currently open files sfs_fcb_t fcbs[MAX_OPEN_FILES]; // The table entries } sfs_ppoft;

32. fs.c Methods int sfs_initialize(int erase); int sfs_init_ppoft(); int sfs_create(char *pathname, int type); int sfs_delete(char *pathname); int sfs_getsize(char *pathname); int sfs_gettype(char *pathname); int sfs_open( char *pathname); int sfs_read(int fd, int start, int length, char *mem_pointer); int sfs_write(int fd, int start, int length, char *mem_pointer); int sfs_readdir(int fd, char *mem_pointer); int sfs_close(int fd);

33. Demonstration Demo code …

34. Advantages of Detailed Design Ensures the system will be able to meet all of the initial requirements Create the program in a systematic manner A good design allows for easier implementation Resulting code is more efficient ◦ Compact, reusable code design

35. Conclusion Lessons Learned / Difficulties ◦ Testing the system (hexdump) ◦ Being able to handle different error situations ◦ Dealing with memory leaks ◦ Meeting all specifications of design

36. Improvements Modify the system to create a file system that incorporates all of the features of a UNIX FS ◦ Variable disk size / data block size ◦ Incorporate more information in the inode ◦ Multiple processes accessing file system ◦ More efficient storage of data in the super block