Jia  Rao
Department  of  Computer  Science   hCp://www.cs.uccs.edu/~jrao
CS4500/5500   UC.  Colorado  Springs   Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester

•   Processes  and  threads   o
Abstrac0on  of  processor  execu0on
•   Memory  management   o
Abstrac0on  of  physical  memory
•   File  systems   o
Abstrac0on  of  persistent  data  storage  on  disks
CS4500/5500   UC.  Colorado  Springs   Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester

Three  essen0al  requirements  for  long-­‐term  informa0on  storage
•   Must  store  large  amounts  of  data
•   Informa0on  stored  must  survive  the  termina0on  of  the  process  using   it
•   Mul0ple  processes  must  be  able  to  access  the  informa0on   concurrently
A  file  is  an  abstrac-on  of  the  long-­‐term  (persistent)  data  storage
The  part  of  an  OS  dealing  with  files  is  the  file  system
What  are  users ’  concerns  of  the  file  system?
What  are  implementers ’ concerns  of  the  file  system?
CS4500/5500   UC.  Colorado  Springs   Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester

°   Files  are  an   abstrac'on  mechanism
•   two-­‐part  file  names
CS4500/5500   UC.  Colorado  Springs   Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester

•   Three  kinds  of  file  structures   o
Unstructured  byte  sequence  (Unix  and  WinOS  view)   o
Record  sequence  (early  machines ’  view)   o
CS4500/5500
Tree  (mainframe  view)
UC.  Colorado  Springs   Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester

°   Regular  files
•   ASCII  files  or  binary  files
°   Directories
°   Character  special  files
°   Block  special  files
Standard  binary
Format  in  Unix:
ELF
CS4500/5500   UC.  Colorado  Springs   Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester

•   Sequen0al  access   o   read  all  bytes/records  from  the  beginning   o   o   cannot  jump  around,  could  rewind  or  back  up   convenient  when  medium  was  mag  tape
•   Random  access   o   bytes/records  read  in  any  order   o   o   essen0al  for  data  base  systems   read  can  be  …
}   move  file  marker  (seek),  then  read  or  …
}   read  and  then  move  file  marker
CS4500/5500   UC.  Colorado  Springs   Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester

In  Linux,  us   stat to  check  file  aCributes
CS4500/5500   UC.  Colorado  Springs   Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester

4.
5.
6.
1.
2.
3.
Create
Delete
Open
Close
Read
Write
7.
8.
9.
10.
11.
Append
Seek
Get  aCributes
Set  ACributes
Rename
CS4500/5500   UC.  Colorado  Springs   Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester

An  Example  Program  Using  File  System  Calls
CS4500/5500   UC.  Colorado  Springs   Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester

An  Example  Program  Using  File  System  Calls  (cont.)
CS4500/5500   UC.  Colorado  Springs   Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester

°   OS  provide  a  way  to  map  files  into  the  address  space  of  a  running   process;   map()  and   unmap()
•   No  read  or  write  system  calls  are  needed  thereaher
(a)  Segmented  process  before  mapping  files  into  its  address  space
(b)  Process  aher  mapping
exis0ng  file   abc  into  one  segment
crea0ng  new  segment  for   xyz
Increased  performance
1.
Accessing  local  virtual  address  is  faster
2.
Avoiding  data  copy  from  kernel  to  user
CS4500/5500   UC.  Colorado  Springs   Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester

Directories:  Single-­‐Level  Directory  Systems
•   A  single-­‐level  directory  system  is  simple  for  implementa0on   o   contains  4  files   o   owned  by  3  different  people,  A,  B,  and  C
What  is  the  key  problem  with  the  single-­‐level  directory  systems?
Different  users  may  use  the  same  names  for  their  files
CS4500/5500   UC.  Colorado  Springs   Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester

What  addi-onal  opera-on  required,  compared  with  single-­‐level  directory  systems?
Login  procedure
What  if  a  user  has  many  files  and  wants  to  group  them  in  a  logical  way?
CS4500/5500   UC.  Colorado  Springs   Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester

CS4500/5500   UC.  Colorado  Springs   Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester

•   Absolute  path  name
•   Rela0ve  path  name
A  UNIX  directory  tree
CS4500/5500   UC.  Colorado  Springs   Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester

1.
Create
2.
Delete
3.
Opendir
4.
Closedir
7.
8.
5.
6.
Readdir
Rename
Link
Unlink
What  are  file  system  implementers ’ concerns?
How  files  &  directories  stored?
How  disk  space  is  managed?
How  to  make  everything  work  efficiently  and  reliably?
CS4500/5500   UC.  Colorado  Springs   Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester

°   File  system  layout
•   Most  disks  can  be  divided  into  one  or  more  par00ons
•   BIOS   à MBR  (Master  Boot  Record)
A  possible  file  system  layout
How  to  keep  track  of  which  disk  blocks  go  with  which  file?
CS4500/5500   UC.  Colorado  Springs   Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester

Implemen-ng  Files  (1)  –  Con-guous  Alloca-on
°   Pros:  simple  addressing  and  one-­‐seek  only  reading
°   Cons:  disk  fragmenta0on  (like  Swapping)
(a)  Con0guous   block  alloca1on  of  disk  space  for  7  files
(b)  State  of  the  disk  aher  files   D  and   F  have  been  dynamically  removed
CS4500/5500   UC.  Colorado  Springs   Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester

Implemen-ng  Files  (2)  –  Linked  List  Alloca-on
°   Keep  each  file  as  a  linked  list  of  disk  blocks
•   Pros:  no  space  is  lost  due  to  disk  fragmenta0on
•   Cons:  how  about  random  access?
CS4500/5500
Storing  a  file  as  a  linked  list  of  disk  blocks
UC.  Colorado  Springs   Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester

Implemen-ng  Files  (3)  –  FAT  (File  Alloca-on  Table)
°   FAT:  a  table  in  memory  with  the  pointer  word  of  each  disk  block
•   High  u0liza0on  +  easy  random  access,  but  too   “ FAT ” maybe?
Consider:
A  20  GB  disk
1  KB  block  size
Each  entry  3  B
How  much  space  for  a  FAT?
How  about  paging  it?
CS4500/5500   UC.  Colorado  Springs   Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester

Implemen-ng  Files  (4)  –  Indexed  Alloca-on
°   Grouping  all  pointers  together  in  a  index  block
°   Each  file  has  its  own  index  block  on  disk
°    it  contains  an  array  of  disk  addrs
CS4500/5500   UC.  Colorado  Springs   Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester

Implemen-ng  Files  (4)  –  Indexed  Alloca-on  Example:  I-­‐node
°   i-­‐node:   a  data  structure  lis0ng  the  aCributes  and  disk  addresses  of  the  file ’ s   blocks;  in  memory  when  the  corresponding  file  is  open
Why  i-­‐node  scheme  requires     much  less  space  than  FAT?
CS4500/5500   UC.  Colorado  Springs   Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester

°   How  to  find  the  disk  blocks  of  a  file?
•   Con0guous  alloca0on:  the  disk  address  of  the  en0re  file
•   Linked  list  &  FAT:  the  number  of  the  first  block
•   i-­‐node:  the  number  of  the  i-­‐node
Who  provides  the  informa0on  above?
The  directory  entry  (based  on  the  path  name)
CS4500/5500   UC.  Colorado  Springs   Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester

°   The   directory  entry ,  based  on  the  path  name,  provides  the  informa0on   to  find  the  disk  blocks
What  to  do  for  few  but  long  and  variable-­‐length  file  names?
(a)  A  simple  directory  (MS-­‐DOS/Windows)
Fixed-­‐size  entries
File  names,  aCributes,  and  disk  addresses  in  directory  entry
(b)  Directory  (UNIX);  each  entry  just  refers  to  an  i-­‐node,   i-­‐number  returned
CS4500/5500   UC.  Colorado  Springs   Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester

•   Two  ways  of  handling  long  and  variable-­‐length  file  names  in  directory
(a)  In-­‐line:  compac0on  and  page  fault.       (b)  In  a  heap:  page  fault
CS4500/5500   UC.  Colorado  Springs   Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester

°   How  to  let  mul0ple  users  share  files?
What  if  directories  contain  the  disk  addresses?
CS4500/5500   UC.  Colorado  Springs
File  system  containing  a  shared  file
Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester

°   UNIX  u0lizes  i-­‐node ’  data  structure
•   What  if  a  file  is  removed  by  the  owner?
(a)  Situa0on  prior  to  linking;    (b)  Aher  the  link  is  created
(c)  Aher  the  original  owner  removes  the  file
CS4500/5500   UC.  Colorado  Springs   Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester

°   A  new  file,  created  with  type  LINK,  enters  B ’ s  directory
•   The  file  contains  just  the  path  name  of  the  linked  file
•   Con:  extra  overhead  with  each  file  access,  parsing
•   Pro  1:  Only  when  the  owner  removes  the  file,  it  is  destroyed
-­‐   Removing  a  symbolic  link  does  not  affect  the  file
•   Pro  2:  networked  file  systems
CS4500/5500   UC.  Colorado  Springs   Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester

°   A  virtual  file  system  is  an  abstract  layer  with  common  func0onali0es   supported  by  all  the  underlying  concrete  file  systems
CS4500/5500   UC.  Colorado  Springs   Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester

•   Implemen0ng  files   o   o   o   o
Con0guous  alloca0on
Linked  alloca0on
FAT
Indexed  alloca0on  (I-­‐node)
•   Implemen0ng  directories
•   Sharing  files
•   File  system  management  and  op0miza0ons   o
Free  blocks,  consistency,  performance  …
CS4500/5500   UC.  Colorado  Springs   Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester