Project 6 Supplemental Lecture

1. Project 6Supplemental Lecture Joe Mongeluzzi Jason Zhao Cornell CS 4411, November 30, 2012

2. Administrative Information • CS4410 MP4 is optional for 4411 students. • Project 6 due Friday, December 7th at 11:59 PM. • Office hours will be held this weekend and next week. • Unless otherwise noted on the website. • All regrade requests will get a response.

3. General Notes • These slides generally reveal implementation hints. • You do not have to follow the implementation we describe here! • Consider following the hints only if you are stuck. • Focus on correctness first, then performance later. • mkfs and fsck should be minithread programs. • Compile them as separate programs. • Don’t make mkfs or fsck function calls in your minifile implementation.

4. Getting started • They are set inside main(), before minithread_system_initialize() is called. int main(intargc, char** argv) {use_existing_disk=0;disk_name = “disk0”;disk_flags = DISK_READWRITE;disk_size = 1000;minithread_system_initialize(entrypoint, NULL);} void minithread_system_initialize(proc_tmainproc, arg_targ) {disk_initialize(&disk);install_disk_handler(disk_handler);}

5. On-disk data structures • One disk block for superblock. • May use one block per inode. • Packing more than one inode per block is more efficient and a little more difficult. • Concurrency-related structures should not be on disk. • Reference counters, locks etc. • “Pointers” on the disk refer to disk block number. • Or inode numbers if multiple per block.

6. The Big Picture superblock dir inode dir data file inode file data magic no. type name block no. type data size of disk size name block no. size name block no. root inode direct ptr direct ptr name block no. direct ptr direct ptr first freeinode name block no. indirect ptr first freedata block indirect ptr free block next free block next free block direct ptr direct ptr direct ptr direct ptr indirect ptr indirect ptr

7. The Big Picture block 0 block 1 block 100 block 2 block 102 magic no.: 4411 type: DIR_INODE .. 1 Type: FILE_INODE Hello world! size of disk: 1000 blocks size: 3 entries . 1 size: 12 bytes abc.txt 2 root inode: 1 direct ptr: 100 direct ptr: 102 0 0 0 first freeinode 0 0 free data block: 103 0 block 103 next free block: 104 next free Block: 105 … 0 block 999

8. Superblock superblock • Use disk block 0 for the superblock. • Root inode field contains the value 1. • Since that inode is located at disk block 1 magic number size of disk root inode first free inode first free data block

9. Inodes inode • You can use the same structure for file and directory inodes. • Size: number of directory entries if inode is a directory . • Size: number of bytes of a file if inode is a file inode. inode type size direct ptr 1 direct ptr 2 direct ptr n indirect ptr

10. Directory Data Blocks directory data block • This is just a table with 2 columns. • Directory data blocks are stored in the region of disk reserved for data blocks. • You can’t tell from this table if a certain entry is a file or a directory. • No indirect pointers in this block. name inodeptr name inode ptr name inode ptr name inode ptr name inode ptr name inode ptr name inode ptr name inode ptr name inode ptr

11. Free Blocks free block ptr to next free block • Use the same data structure for free inodes and data blocks. • Just store an integer that points to the next free block. • If the next free block says 0, there are no more free blocks after this. • Returning new blocks to the list: Append or prepend?

12. Data structures for blocks • Structsyou may want: • Superblock • Inode • Directory data block • Free data block • File data block? • How big should each struct be? struct superblock { // members of superblock here }

13. Data structures for blocks • Can apply trick we’ve seen before: struct superblock { union {struct {// Members of superblock here } data; char padding[DISK_BLOCK_SIZE]; }}

14. Benefits • You can cast the struct into a char* and directly use it in disk read and write operations. • The struct is of size DISK_BLOCK_SIZE, so you will read/write exactly one block. • No need to worry about padding.

15. Variations • Remember: you don’t have to follow our suggestions. • As long as your file system is reasonable and concurrent. • Describe your implementation in the README file. • More than one inode per block. • Double/triple indirect pointers, similar to Linux. • Bitmap instead of a free list. • Different structures for blocks.

16. Unacceptable variations • Constricting free expansion for the number of directory entries or file size. However: • Directory and file sizes will not exceed 232 bytes (4Gb). • Storing names in inodes. • Storing directory data or indirect blocks in the inode-reserved section of the disk.

17. Concurrency • Create some in-memory protection structures. • Must be dynamically allocated since disk_size is a variable. • Our suggestion: one ‘big lock’ for metadata accesses that can potentially span multiple inodes. • One lock per inode for file updates. • Lock this inode when performing reading/writing, but release it as soon as you can. • Some way to handle delete of an open directory/file

18. Need more implementation hints? • The Design of the UNIX Operating System, Maurice J. Bach. • Lots of information available online.

19. Parting Quote “Good design comes from experience. Experience comes from bad design.” -Theodore von Karman

20. Questions Questions?