Please enable JavaScript.

Coggle requires JavaScript to display documents.

File Systems (Distributed file system requirements (Transparency (Access…

- - - - Provides a mapping between text names and their UFIDs
      - Creates directories, add/delete files from the directories
      - Client of the flat file service since the directory files are stored there
    - - Integrates the directory service and flat file service
      - Provide whatever application programming interface is expected by the application programs
      - Maintains a list of available file servers
      - Cache data to improve performance
    - - Unique file identifier (UFID) is given to the flat file service to refer to the file to be operated on
      - Creates a new UFID for each new file that it creates
      - Implement operations on file contents
  - - - Makes an access check whenever a file name is converted to a UFID -> results encoded in the form of a capability that is returned to the client for submision to the flat file server
      - User identity can be submitted with every client request
      - Access checks can be performed by the flat file server for every file operation
- - - - Local file: v-node contains a reference tothe file's i-node on the UNIX file system
      - Remote file: v-node contains a reference to the file's NFS file handle (combo of filesystem's identifier, i-node number and whatever else the NFS needs to identity the file)
  - - - User programs can access files via UNIX system calls without recompilation or reloading
      - A single client module serves all of the user-level processes, with a sharred cache
      - The encryption key used to auuthenticate user IDS passed to the server can be retained in the kernel, preventing impersonation by userlevel clients
  - - - Hard-mounted: block on each access until the access is complete
      - Soft-mounted: retry a few times and then return an error to the calling process
  - - - Accesses to cached data does not require a disk access
      - Read ahead: anticipates read accesses, fetches pages following those that have been recently read
      - Delayed write/write back: optimises writes to the disk by only writing pages when they have been modified + evicted.
      - Data read from the disk/pages are retained in a main memory buffer cache and are evited when the bugger space is required for other pages
      - Works because only has one cache, all file accesses cannot bypass the cache
    - - No problems for client reads
      - Client writes need to be persistent. Two options
        
        Write-through: data is written to cache + directly to disk. The operation completes when the data has been written to disk
        
        Increases disk I/O + latency for write operations
        
        Poor when the server receives a large number of write requests for the same data
        
        Saves network bandwidth
        
        Commit: data is written to cache + to disk when a commit operation is received for the data. A reply to the commit is sent when the data has been written to disk
        
        Uses more network bandwidth
        
        May ead to uncommitted data being lost
        
        Receives full benefit of the cache
  - - - T - T_c < t where t = freshness interval, T_c time when a cache block was last validated by a client
        
        Valid, do nothing
        
        Not valid, check modification time
      - T{m, client} = T{m, server} where T_m = time when a block was last modified
        
        Valid, update T_c
        
        Not valid, request a new copy from server
      - Check freshness first! No need network I/O. If false, check modification time
      - Traffic can be reduced by applying new values of T_{m, server} to all reclevant cache blocks + piggy-backing attribute operations on every file operation
- - - - Client programs should be unaware of the distribution of files
      - Same API for accessing local + remote files -> programs written to operate on local files can, unchanged, operate on remote files
    - - Client programs should see a uniform file name space
      - Files names should be consistent regardless of storage location + where the clients are accessing from
    - - Client programs and admin services do not need to change when files are moved
    - - Client programs should continue to perform satisfactorily while the load on the service varies within a specified range
    - - The service can be expanded by incremental growth to deal with a wide range of loads and network sizes