23
CSCI 3431: OPERATING SYSTEMS Chapter 10 – File-System Interface (Pgs 421-457 )

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

Embed Size (px)

Citation preview

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

CSCI 3431: OPERATING SYSTEMS

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

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

Handling a Page Fault (9.6)

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

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 ...

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

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

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

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

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

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.

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

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)

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

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

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

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.

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

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)

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

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

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

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)

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

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)

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

To Do:

Work on Assignment 2 (Due next week)

Read Chapter 10 (pgs421-457; this lecture)

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