Computer Science and Engineering Four Hundred and Fifty One Project 3 The lecture kheimerl@ ak@

Project 3 Work with a real file system Given: Goals: cse451fs: simplified file system for Linux Goals: Understand how it works Modify implementation to: Increase maximum size of files (currently 13KB) Allow for longer file names (currently 30 chars) Increase the maximum number of files (currently 8k)

Linux FS layers User apps VFS Buffer cache Disk drivers  Common FS interface cse451fs ext2 ext3 vfat Buffer cache  $ for disk blocks Disk drivers

File systems in Linux Layered on top of a block device Device provides a big array of blocks Blocks are cached in the buffer cache Implement a standard interface file_operations read/write/seek files; read directory inode_operations create / lookup / unlink / mkdir / rmdir / rename super_operations read/write inodes address_space_operations readpage/writepage for memory-mapped IO file_system_operations read in superblock Linux defines an Inode struct that you must also translate internal data structures into when passing them to the kernel.

The Linux VFS API The Directory Cache Inode Handling d_invalidate — invalidate a dentry d_find_alias — grab a hashed alias of inode prune_dcache — shrink the dcache shrink_dcache_sb — shrink dcache for a superblock have_submounts — check for mounts over a dentry shrink_dcache_parent — prune dcache d_alloc — allocate a dcache entry d_instantiate — fill in inode information for a dentry d_alloc_root — allocate root dentry d_lookup — search for a dentry d_validate — verify dentry provided from insecure source d_delete — delete a dentry d_rehash — add an entry back to the hash d_move — move a dentry __d_path — return the path of a dentry is_subdir — is new dentry a subdirectory of old_dentry find_inode_number — check for dentry with name d_drop — drop a dentry d_add — add dentry to hash queues dget — get a reference to a dentry d_unhashed — is dentry hashed Inode Handling __mark_inode_dirty — internal function write_inode_now — write an inode to disk clear_inode — clear an inode invalidate_inodes — discard the inodes on a device get_empty_inode — obtain an inode iunique — get a unique inode number insert_inode_hash — hash an inode remove_inode_hash — remove an inode from the hash iput — put an inode bmap — find a block number in a file update_atime — update the access time make_bad_inode — mark an inode bad due to an I/O error is_bad_inode — is an inode errored Registration and Superblocks register_filesystem — register a new filesystem unregister_filesystem — unregister a file system __wait_on_super — wait on a superblock get_super — get the superblock of a device get_empty_super — find empty superblocks

Remote Mounts Dev/sda1 / Dev/sda2 /foo You can mount any physical space to any location mount –t type device dir Ex: mount –t ext3 dev/sda2 / mount –t nfs /tantanga/uns /uns Dev/sda1 / Dev/sda2 /foo This stores the device/path pair somewhere and looks it up when you use a command. Ex: Chart above ls / will look in table, find longest path, “/” ls /bar will do same ls /foo/bar will look in table, find longest path “/foo”

Project 4 Setup Build a kernel module for cse451fs (and a kernel supporting cse451fs) Transfer it to VMware On VMware, use the virtual disk drive to test your file system. load cse451fs Make a file system using (modified) mkfs tool mount, test Step 1: try this procedure with given code Step 2: read cse451fs.h, then dir.c Need to change this? Or let them use the ramdisk?

cse451fs disk structure Superblock: tells where all other things are Contains inode map: Bit array, tracks which inodes are currently in use E.g. for 3 dirs + 4 files, need 7 inodes Data map: Bit array, tracks which data blocks are in use

cse451fs structure 1 1 1 85 4008 struct cse451_super_block { 1365 __u16 s_nNumInodes; // inode map is tail of superblock 2 __u16 s_nDataMapStart; // block # of first data map block 1 __u32 s_nDataMapBlocks; // data map size, in blocks 3 __u32 s_nInodeStart; // block # of first inode block 85 __u32 s_nNumInodeBlocks; // number of blocks of inodes 88 __u32 s_nDataBlocksStart; // block # of first data block 4008 __u32 s_nDataBlocks; // number of blocks of data 7 __u32 s_nBusyInodes; // number of inodes in use 0x451f __u16 s_magic; // magic number unsigned long s_imap; // name for inode map }; Sample values for a 4MB disk with 4 files and 3 dirs using 1K blocks

Inode structure Inode size? Multiple inodes per block! #define CSE451_NUMDATAPTRS 13 struct cse451_inode { __u16 i_mode;  determines if file or dir __u16 i_nlinks; (+ protection) __u16 i_uid; __u16 i_gid; time_t i_atime; <- the most recent access time time_t i_mtime; <- the most recent modification time time_t i_ctime; <- creation time __u32 i_filesize; __u32 i_datablocks[CSE451_NUMDATAPTRS]; }; Inode size? Multiple inodes per block! How many for 1K block? mkfs decides how many inodes to create mk451fs.c : create an inode for every three data blocks

Data blocks Blocks for regular files contain file data Blocks for directories contain: #define CSE451_MAXDIRNAMELENGTH 30 struct cse451_dir_entry { __u16 inode; char name[CSE451_MAXDIRNAMELENGTH]; }; Data block for / directory containing: . .. etc bin What’s this dir’s inode number? What is the “file size” field in this dir’s inode? Directory block for / Entry Field Value Inode 1 Name “.” “..” 2 “etc” 3 “bin” 4

Sample data block usage For a 4MB file system with 1KB blocks / etc passwd fstab bin sh date File/Directory Size Data Blocks / 4 entries + 1 null entry 1 /etc /bin /etc/passwd 1024 bytes /etc/fstab 100 bytes /bin/sh 10,000 bytes 10 /bin/date 5,000 bytes 5 Total: 20

Project 4 requirements Increasing maximum size of files Be efficient for small files but allow large files Changing constant (=10) is not enough. Come up with a better design/structure for locating data blocks. Indirect blocks? Don’t have to support arbitrarily large files But support at least 256KB for full credit You can implement support for arbitrarily large blocks, but it still must be efficient! So solve the 256KB first, then this Allow for longer file names Be efficient for short files names but allow large file names Again, don’t just change the constant

Approaches for longer file names Store long names in a separate data block, and keep a pointer to that in the directory entry. Short names can be stored as they are. Recommended Combine multiple fixed-length dir entries into a single long dir entry (FAT 16) It is easier if the entries are adjacent. Put a length field in the dir entry and store variable length strings need to make sure that when reading a directory, that you are positioned at the beginning of an entry.

Getting started with the code Understand the source of the limits in the existing implementation Look at the code that manipulates dir entries mkfs code dir.c in the file system source code Longer file names: The code for will largely be in dir.c: cse451_add_entry() and cse451_find_entry() In mkfs, change how the first two entries (for “.” and “..”) are stored Bigger files: super.c:get_block() References to i_datablock[] array in an inode will have to change

VFS vs cse451fs Don’t conflate VFS structures and cse451fs structures! inodes, superblocks E.g., there are “two” inodes: VFS struct inode Generic inode used in Linux source (works for any FS) Lives in memory cse451 struct cse451_inode Actual inode representation on disk inode.c:cse451_read_inode converts from cse451_inode to struct inode Copies over mode, size, etc Copies over i_datablocks[] to struct inode’s generic_ip field (which will now be used as type cse451_inode_info) inode.c:cse451_write_inode converts the other way

Linux Buffer Manager Code To manipulate disk blocks, you need to go through the buffer cache include/linux/buffer_head.h fs/buffer.c Linux buffer cache fundamentals: blocks are represented by buffer_heads Just another data structure Actual data is in buffer_head->b_data For a given disk block, buffer manager could be: Complete unaware of it no buffer_head exists, block not in memory Aware of block information buffer_head exists, but block data (b_data) not in memory Aware of block information and data Both the buffer_head and its b_data are valid (“$ hit”)

Accessing blocks To read a block, FS uses sb_bread(…): Find the corresponding buffer_head Create if doesn’t exist Make sure the data is in memory (read from disk if necessary) To write a block: mark_buffer_dirty() + brelse() - mark buffer as changed and release to kernel (which does the writing)

Some buffer manager functions cse451_bread(pbh, inode, block, create) Get the buffer_head for the given disk block, ensuring that the data is in memory and ready for use. Increments ref count; always pair with a brelse. cse451_getblk(pbh, inode, block, create) Get the buffer_head for the given disk block. Does not guarantee anything about the state of the actual data. Increments ref count; always pair with a brelse. Zeros out new blocks (required for security). brelse(bh) Decrement the ref. count of the given buffer. mark_buffer_dirty(bh) Mark the buffer modified, meaning needs to be written to disk at some point. mark_buffer_uptodate(bh) Indicate that the data pointed to by bh is valid.

Hints Learn how to use sb_bread/brelse and other buffer cache stuff by looking at provided code All printk messages stored in /var/log/messages Can view to examine long debug outputs Q: “It is extremely frustrating not to be able to read debug messages because they scroll off screen in vmware so quickly :(” A: Use Shift-pageup and Shift-pagedown Q: “How does ls get its entries?” dir.c:readdir()

A gcc warning gcc might insert extra space into structs How big do you think this is? struct test { char a; int b; } Why is this a problem? What if test represents something you want on disk? e.g. directory entries Discrepancy between the disk layout and memory layout Fix: struct test2 {      char a;      int b; } __attribute__((packed)); sizeof(test2) is now 5

More hints Some stuff in linux kernel is limited to 256 chars e.g. VFS, ls Be careful when testing long filenames! dd is useful for creating large test files dd if=/dev/zero of=200k bs=1024 count=200 df is useful to check you’re freeing everything correctly

More & more hints Provided mkfs has useful functions Dump data map Print inode contents/map Print superblock Use lots of existing programs to test cp, tar, mv, diff … Recursive option is useful to test file & directory routines in a single execution Be aware of buffer cache! Change to the file system may not be reflected instantly

Notes Efficiency is not THE concern. Efficiency is A concern. So don’t worry too much Efficiency is A concern. A 256KB linked list is not an acceptable answer. Lookup time should scale well with file size. Don’t do anything monumentally stupid and you should be good. Use forkbomb Send a reasonable tar file Omg-project1-hi_mom.tar.gz <- NO Username.tar.gz <- YES