1 / 59

File System

제 05 강 : File System. File System. 1. Data Structure 2. Functions. Kernel Data Structure for File. Process 1. Process 2. PCB. PCB. CPU. mem. FCB. CPU. mem. File. : Table (Data Structure) : Object (hardware or software). Meta-data for a File.

svein
Download Presentation

File System

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 제05강 : File System File System 1. Data Structure 2. Functions

  2. Kernel Data Structure for File Process 1 Process 2 PCB PCB CPU mem FCB CPU mem File : Table (Data Structure) : Object (hardware or software)

  3. Meta-data for a File • Information kernel needs for a file: • owner (eg Clinton) • protection (eg rwx r-- r--) • device (eg disk) • content (eg. sector address) • device driver routines (eg read(), open() ) • accessing where now (eg offset*) • …. • In Linux kernel, read/write system call is sequential. • Try “man 2 read” for system call parameters.  offset assumed. • For random access, use lseek() system call that moves offset.

  4. contiguous allocation scattered allocation

  5. Contents of File FAmay be stored in disk non-contiguously*in units of disk sectors File content • Why not contiguous allocation? • (O) fast – if R/W whole content • sequential • use for swap, device copy, … • (X) space management • many small holes (useless) • external fragmentation File content File content File content

  6. Kernel maintains metadata for each file File metadata File content File content File content File content

  7. File metadata includes pointers to data sectors File metadata File content File content File content File content

  8. Open()retrieves metadata from disk to main memory File metadata File metadata File content File content File content File content But not contents – they are too big !!

  9. This metadata has pointers to data sectors File metadata File metadata File content File content File content File content

  10. Split Metadata for file PA FX metadata FX metadata FX metadata PB File content File content File content FX metadata File content PC

  11. Split Metadata for file Systemwide information All processes share single copy in memory “inode” struct • owner • protection information • device • pointer to file content • device driver routines • offset Private information Let each process have private copy since processes access different part “file” struct

  12. So we have two data structures for each file Private information Systemwide information inode table (system) file table PA offset other info. offset PB private info Per-process data Next byte position to r/w shared info (systemwide) single copy globally Information --- less frequently changed

  13. /* * One file structure is allocated for each open/creat/pipe call. * Main use is to hold the read/write offset */ struct file { char f_flag; char f_count; /* reference count */ int f_inode; /* pointer to inode structure */ char *f_offset[2]; /* read/write character pointer */ } file[NFILE]; /* flags */ #define FREAD 01 #define FWRITE 02 #define FPIPE 04

  14. struct inode { char i_flag; char i_count; /* reference count */ int i_dev; /* device where inode resides */ int i_number; /* i number, 1-to-1 with device address */ int i_mode; char i_nlink; /* directory entries */ char i_uid; /* owner */ char i_gid; /* group of owner */ char i_size0; /* most significant of size */ char *i_size1; /* least sig */ int i_addr[8]; /* device addresses constituting file */ int i_lastr; /* last logical block read (for read-ahead) */ } inode[NINODE];

  15. Sharing Files • Example • (Case-1) who, grep -- pipe file • % who | grep • share inode (pipe file), • not share offset • (Case-2) parent/child -- tty file • % vi • share inode (tty file), • share offset pipe who grep tty(in) sh vi

  16. Sharing files (system) file table Inode table tty device who offset pipe inode grep $ grep|who offset inode process group sh offset vi $ vi Pipe file offset inode game file game

  17. Device switch table • 2-dim array which maps (device name, operation name) => device driver routine device independence (above: file, below: device) devswtab[]: open close read write ioctl Read_lp Starting address of driver routine

  18. Actually, one dimensional array of struct not two dimensional array struct cdevsw { int (*d_open)(); int (*d_close)(); int (*d_read)(); int (*d_write)(); int (*d_sgtty)(); } cdevsw[]; d_open d_close d_read d_write d_ioctl Read_lp

  19. Kernel tables after open(/a/b) PA user (system) file table inode table / / b a a data block data block data block b Device name

  20. Kernel tables after open(/a/b) PA user (system) file table inode table / / b a a data block data block data block offset b

  21. Kernel tables after open(/a/b) PA user (system) file table inode table / u-ofile / 0 1 2 3 4 b a a fd = 4 data block data block data block offset b

  22. File descriptor table(or open file table) • An array in struct user ( u_ofile[] array ) • per process open file information • whenever program calls open(), create() fd = open(“/a/b”, …) • fd is integer (“file descriptor”), starts from 0, 1, 2 .. • 0, 1, 2 reserved for standard (input/output/error) file • used as an index into • u_ofile[] array (file descriptor table, open file table_) • starting point to access file (points to system file table) (3) file descriptor (2) kernel (1) pathname of is returned opens file the file to open Internal rep. symbolic name

  23. PA Kernel data structure for file userper process (system) file table inode table devswtab u_ofile[] offset inode 0 1 2 3 4 routine fd offset device inode open file table file descriptor table ( “file handle” extends this notion to network. Window’s name)

  24. Kernel Data Structure Process 1 r w o c user devswtab offset inode read( ) CPU CPU FX

  25. (System) file table • struct file • One entry for each open/create/pipe • may be shared (if offset is shared) • content • offset • counter (number of processes sharing this entry) • pointer to inode table • r/w/p flag

  26. Inode table • includes most of the information for file • shared by all processes • changed less frequently (than offset) • content (while in disk) • protection mode • owner • size • pointer to sectors • etc

  27. In core Inode • content (while in disk) • protection mode • owner • size • time • array of pointers to disk blocks • plus (at load time) • counter (number of processes sharing file) • device name (major/minor device number) • i-number (location of inode in disk) • status (locked, mount point, …)

  28. Now, you can reach any data block through in-core inode These pointers are stored in an array within inode pointer array within inode inode inode File content File content File content File content

  29. ~50 Balanced tree • Example: 10 GB disk, 1K sector  # of sectors = 10,000,000,000 / 1000 = 10,000,000 sectors each sector pointer ----- 24 bits • A sector can hold (1000/24) = about 50 sector pointers

  30. ~50 ~50 ~50 ~50 Balanced tree • Example: 10 GB disk, 1K sector  # of sectors = 10,000,000,000 / 1000 = 10,000,000 sectors each sector pointer ----- 24 bits • A sector can hold (1000/24) = about 50 sector pointers

  31. ~50 ~50 ~50 ~50 ~50 ~50 ~50 Balanced tree • Example: 10 GB disk, 1K sector  # of sectors = 10,000,000,000 / 1000 = 10,000,000 sectors each sector pointer ----- 24 bits • A sector can hold (1000/24) = about 50 sector pointers

  32. Balanced tree • Balanced tree of order ~ M (special insert/delete algorithm) • Top level, master index • UNIX – skewed tree

  33. pointer array within inode Data Block direct 0 direct 1 direct 2 direct 3 direct 4 direct 5 direct 6 direct 7 direct 8 direct 9 single indirect double indirect triple indirect

  34. pointer array within inode Data Block direct 0 direct 1 direct 2 direct 3 direct 4 direct 5 direct 6 direct 7 direct 8 direct 9 single indirect double indirect triple indirect Fast for small files (created by human being at terminal keyboards) slower for big files timesharing application

  35. Offset vs Disk Block Data Block direct 0 direct 1 direct 2 direct 3 direct 4 direct 5 direct 6 direct 7 direct 8 direct 9 single indirect double indirect Triple indirect ~ 1KB ~ 2 KB ~ 9 KB ~109KB ~ 10109 KB 57821

  36. Linux • 1-12th pointer – direct pointer • 13th pointer – indirect pointer • 14th pointer - doubly indirect pointer • 15th pointer – triply indirect pointer • --------------- • Max 4096 GB file data if • block address - 32 bits • block size - 4096 byte

  37. Disk Space for ... inode Space for inode Space for data blocks inode inode inode data block data block data block data block File data size --- varies inode size --- fixed

  38. Space for inode in Disk (Each inode - fixed size) inode 0 i-number: ordinal number (順番) of inode in disk If I know (disk, i-number), I can access file content. disk name inode content i-number inode 1 inode 2 inode n

  39. Directory file (it is also a file.  content: <name, pointer>) i-number = 3 3rd inode in disk Q: file name – limit char? Q: # of files – limit? Data blocks

  40. Kernel tables before open(/a/b) PA user (system) file table inode table / inode data / b a data block data block data block

  41. a bin x 7 11 8 Kernel tables before open(/a/b) PA file table user inode table data block data block data block / inode data / b a data block data block data block

  42. b usr y 3 21 6 a bin x 7 11 8 Kernel tables before open(/a/b) PA file table user inode table data block data block data block / inode data / b a data block data block data block data block data block data block a

  43. open(“/a/b”) data /: Directory Directory Regular File a x y bin dev 7 6 8 11 40 i data data data /a: w u b ch temp 7 6 8 11 40 i data data data /a/b: Content of this file i data data

  44. open(“/a/b”, …) • Kernel system call open( ) scans pathname • 1st -- root directory file: • get inode 0 in disk inode space • read data blocks of root directory file • search for file name “a” • get corresponding i-number for file “a” • 2nd -- “a” file: • get inode of file “a” from disk (it is directory file) • get data blocks of directory file “a” • search for file name “b” • get corresponding i-number for file “b” / a / b a 7 bin 12 dev 11 / a / b

  45. (continued) / a / b • file “b”: • read inode of “b” from disk (regular file) ---- given pathname “/a/b” ends here ------- • set up kernel data structures for file “b” • insert inode into in-core inode table • new entry in system file table (offset <= zero) • new entry in u_ofile[] in user • return file descriptor • open( ) is done

  46. Kernel tables after open(/a/b) PA user (system) file table inode table / inode data / b a a data block data block data block

  47. Kernel tables after open(/a/b) PA user (system) file table inode table / / b a a data block data block data block b Device name

  48. Kernel tables after open(/a/b) PA user (system) file table inode table / / b a a data block data block data block offset b

  49. Kernel tables after open(/a/b) PA user (system) file table inode table / u-ofile / 0 1 2 3 4 b a a fd = 4 data block data block data block offset b

  50. Kernel tables after open(/a/b) PA user (system) file table inode table fd = 4 returned / u-ofile / 0 1 2 3 4 b a a data block data block data block offset b Once you have fd, you can access b’s inode after only 3 memory accesses

More Related