chapter 10 – file-system interface (pgs 421-457 )

CSCI 3431: OPERATING SYSTEMS

Chapter 10 – File-System Interface (Pgs 421-457 )

Handling a Page Fault (9.6)

Page Fault Sequence1. Trap to operating system2. Jmp to page fault handler3. Save registers and state4. Determine validity of address5. Block process in IO queue6. Identify an available frame

1. If none: Apply page replacement policy2. If needed, issue a disk write to save the page being replaced3. After page write, disk trap to operating system

7. Issue a disk read8. Run scheduler, execute another process ...9. After page load, Disk trap to operating system10. Jmp to disk interrupt handler11. Figure out the disk was handling a page fault12. Update page table for process, unblock process, reset process so

it can resume at failed instruction13. Run scheduler, execute some process14. ... Resume where we left off when we are scheduled to run ...

Overview

Information can be organised in a variety of ways to describe its logical structure Database: Tables & Records Spreadsheet: Sheets, Rows, Columns IR: Documents WWW: Pages

In an OS, data is treated as files, which is really just another logical structure

For some OSs, the file model isn`t suitable (Google OS), and thus alternatives are used

File

Named set of contiguous (ordered) bytes

Typically the smallest unit by which a user can use secondary storage (e.g., disks, CDs)

File structure and data encoding within the file are an application concern and have minimal impact on the OSFILE = Named and Ordered Collection

of Binary Data

File Attributes

Name Identifier – Name used by OS, permits

duplicate names etc. Type – Only of value if OS somehow treats

different file types differently – e.g., thumbnails of graphical images

Access mode (r,w,a) Size – current and/or maximum allowed Protection – Permissions, owner, group Administrative – Last read, last write, creation

time, last user, number of accesses, etc.

File Operations

1. Create – a new empty file2. Delete – an existing file3. Read – some part of a file4. Write – to somewhere in the file (c.f., insert vs.

replace) These can be combined, such as "truncate"

which is basically "delete and create new (of the same name)"

Seek is not really an operation, its an element of an access technique using file pointers

May also have: locking, security (permissions), etc.

File Access

Basic ops: Create, delete, read, write Various interfaces are possible, one common one

is the use of file pointers (C), streams (C++, Java) Other interfaces exist (e.g., records in COBOL) Need to differentiate Language Level Interfaces

vs. OS (system call) Interfaces1. Open: Get a pointer2. Close: Delete it3. Seek: Move it to somewhere in the file4. Read: Get data starting at the pointer5. Write: Overwrite/append starting at the pointer

Access Issues

Locking and number of users (Open file pointers) – various ways this can be provided

File location – disk vs. memory, buffering of parts

Access rights -- permissions Access modes – r,w,a

File Types

OS can sometimes do more intelligent things if it knows how the data in a file is encoded/stored

Need a mechanism that is very flexible/extensible

Typical to indicate format as part of name Became formalised (in some OSs) as the file

(name) extension (e.g., .pdf, .doc, .html), but some OSs (i.e., Unix) ignore file extensions

Mostly an application/user concern, not really relevant to the OS

File Structure

A file is a stream of bytes – what more does an OS really need to know

Different OS have imposed different file structures, but it tends to hinder portability

Application programmers tend to dislike rigid formats

It can be beneficial, but it is not really needed, to structure data in a file so that it doesn't span disk blocks

So Far ...

Section 10.1 rambles on about File Properties Files are just a bunch of bytes Bytes need to move from disk to memory from memory to disk Whether these bytes are new or came from

disk originally doesn't really matter Programs use an interface to

create/delete/read/write to this set of bytes The bytes are ordered, applications do not

tolerate them being scrambled when moved around

Access Methods

Sequential – more historic, from the time of paper tapes which could not be easily rewound

Random/Relative/Direct – Can access anywhere in the file

Indexed – Access is always via an index structure

RWA: 1. Read only2. Write (and read) 3. Append only

File System Structure

Memory is structured in pages Disks are structured in blocks Data is moved between the two Data can also be moved around in

memory, on disk, to CDs Files merely provide a logical model for

users and programmers The large number of files requires the

imposition of some organisational model

File Systems

There are many ways of organising files

Disks sometimes use several organisations

Break disks into parts (i.e., partitions) in which each part has a different organisational structure

To improve performance, files are sometimes stored in memory, and thus entire file systems can also be created in memory (i.e., virtual file systems)

Directories

*insert yawn here*

There can be a lot of files One (somewhat dying) model for storing data is

the use of a directory We all know what a directory is ... A table that

lists a bunch of files and provides the OS with information for retrieving these files

It is probable that IR techniques will replace directories for many general purpose user activities

Browse (navigate) vs. Retrieve (search)

Directory Structures

Single level – One huge table Hierarchical (Tree Structured) – A directory

can contain other directories (special cases such as n-level may exist)

Web (Graph Structured) – Directories can contain references to other directories and thus form information graphs, may be acyclic or cyclic

View as imposing limits on the graph modelCyclic Acyclic Tree Flat

Main issue with cycles is search

Mounting

Telling the OS which parts of the disk can be used

Identifying how the files are structured on that part of the disk

Usually done as part of the OS boot sequence, but may be done manually

Also consider mounting of networked (external) drives etc.

File Sharing

Two main issues1. Security of Data2. Integrity/Consistency of Data Complicated by file location and

network properties (for non-local files)

A. Local files (i.e., attached disk)B. Files on the same LAN (i.e., local

ethernet)C. Files via WAN (i.e., Internet)

OS vs Network

For non-local resources, it can be effective to consider a client-server model

When an OS does more than access/maintain the local hardware, it requires some communication method (i.e., a network)

OS should support networking, but in general its a set of layers added on top of the OS

Most network designers/programmers have a strong understanding of OSs

Various levels of OS:Network cohesion are possible (from none, to highly integrated)

Will not really discuss networking much in this course

Consistency

Read/Write locks – e.g., sign in/out in CMS

Transaction models (can undo actions)

Concurrency calculi Single-user model Only relevant if a file can be1. shared2. written Also considered due to errors (read

failures)

Protection

User properties: Groups, Ownership, Creator

File properties: rwx, append, delete, exists?

System properties: buffering, IO in progress

Properties may be permanent or transient Sometimes augmented by additional add-

on protocols/tools (e.g., encryption, embedded passwords)

To Do:

Work on Assignment 2 (Due next week)

Read Chapter 10 (pgs421-457; this lecture)

Read Chapter 11 (pgs 461-499; next lecture)