120 likes | 266 Views
File System FAQ. Fs_init() vs. fs_mkfs(). What need to be done where: FS_init() takes care of system wise FS related initialization (Related to the running system). FS_mkfs() is doing the initialization of the FS itself. (Related to the specifics of FS on disk) How to tell:
E N D
Fs_init() vs. fs_mkfs() • What need to be done where: • FS_init() takes care of system wise FS related initialization (Related to the running system). • FS_mkfs() is doing the initialization of the FS itself. (Related to the specifics of FS on disk) • How to tell: • Think what will happen if you have two disks in your system (How you separate work)
Fs_init() vs. fs_mkfs() (cont.) • When to init file descriptor table. • When to set bitmaps and inodes to be free. • When to initialize currentInode (correspond to “/”)
Directory structure • Disk layout vs memory layout: common.h typedef struct { char name[MAX_NAME]; int inodeNo; char dummy[DIRECTORY_ENTRY_SIZE - MAX_NAME - 4]; } dirEntry; #define MAX_NAME 32 #define MAX_INODE_DIGITS 31 #define DIRECTORY_ENTRY_SIZE (MAX_NAME+MAX_INODE_DIGITS+1) #define INVALID -1
Inode contents • Opens: To keep track of concurrent opens for this file. (No need to put them on disk) • Links: To keep track of number of hard links.
Fs_lseek() semantic. • Our fs_lseek() only takes two arguments • fd, offset • Unix lseek() takes three • fd, offset, whence • Whence: SEEK_SET, SEEK_CUR, SEEK_END • So our fs_lseek() will assume one of them • SEEK_SET, if you prefer other, put that in your README file. • What if lseek() want to seek after end of file?
Pathname (Absolute pathname?) • Do we need to support absolute pathname • Eg: When I am in “/foo”, do I need to support: chdir /bar/tmp/ • You do not need to do that for this project. (Otherwise, you would have to support absolute pathname everywhere: open, link, mkdir… etc)
Remove directory • Do I need to support removing directory that are not empty? • Ie: Remove all the subdirectories and files contained in the parent directory when removing parent directory? • No. Just return error when the directory to be removed is not empty.
Treat directory as file? • What does it mean; why? • If you treat directory as file, then you can use your existing function to handle file I/O to do directory manipulation. (Avoid duplicate efforts internally.) • Say if you want to implement indirect blocks (both for file and directory) • If you treat directory same as file, then you would not need to worry about indirect blocks when you are working on the directory.
Can I modify fs_fsck and others • Yes. If you have different disk layout or assumptions than ours. (But make sure you still have a correct fs_fsck! Also document them in README.) • Also if you implement extra credits, you would have to make fs_fsck correct as well.
Synchronous operation • Can I cache directory, inode, bitmap … etc to speed up FS? • Yes. But for this project, your first priority is to make it correct. (ie, if power failure occurs, your FS should still be in consistent state.) So better make them synchronous. • If you make them work, you can get extra credit!!
Want some more for Christmas?! • If you think you have fancy ideas to improve our FS, you can get extra credits. Please email me on what you want to do and we can discuss them. • Potential ideas: (Other than on web) • Implement buffer cache (1 credit?) • Implement write ahead log (2 credits?) • Implement a good automated test suite using “expect”? (1 credit?)